Fix comment and manual dispatch triggered build jobs #723

psobolewskiPhD · 2025-05-28T01:34:39Z

References and relevant issues

Currently, comments are not properly triggering jobs.
The primary issue is that comment triggers are from the main branch context and not PR context.
For circleCI it's even harder, because if you checkout the PR and then run CircleCI it will still internal checkout the wrong branch.
Also reporting back to the PR was also not working.
I did some googling and sorted out a pathway using CircleCI-Public/trigger-circleci-pipeline-action
-- not sure how I missed it before?
Also consulted Claude a bit.

Description

I ended up re-doing the whole action, so I gave it a new name. I think the diff would be atrocious, so this is easier.
The main change here are as follows. First for the Circle part:

To use https://github.com/CircleCI-Public/trigger-circleci-pipeline-action in the action, we need to adjust the circleci/config.yaml to add the pipeline parameters required by the action and also switch to using a job parameter for the make target. Then we can use workflows for circleCI that are conditional on the GH_Meta pipeline parameter. The net result is that the right make target is used.
Use https://github.com/CircleCI-Public/trigger-circleci-pipeline-action which lets us pass the PR branch (this isn't well documented, but works) via target-branch, as well as the desired make target in GH_Meta. The best part is the status reporting then works for both the Circle job and the redirector 🎉
We get the target-branch from the "PR details" step of the first job determine-make-target

Importantly, this also sets us up for a followup PR to check for a label and run full build. With this implementation that will be trivial by comparison.

Now for the artifact build:

The key is the job is again getting those PR details. Then we use the right branch for the reusable workflow and get the right artifact built. For this we add the extra workflow_call parameter so we can pass the PR detail to the job.
The issue is with the status reporting. Again the context being the main branch of the repo, getting the reusable action status is tricky. myrotvorets/set-commit-status-action ended up being very useful for this simplifying a ton vs. the old approach.
Fun part:

Added the eyes reaction to show that the comment was received.

I made the PR branch my main branch in my fork and then opened a PR vs that, which you can find here:
psobolewskiPhD#90
You can see that things came together and work!
Feel free to try a comment!

psobolewskiPhD · 2025-05-28T01:35:49Z

.circleci/config.yml

 # Orbs are reusable packages of CircleCI configuration that you may share across projects.
 # See: https://circleci.com/docs/2.1/orb-intro/
 orbs:
  python: circleci/python@3.0.0

-# parameterize the make target used for build, passed in from build_trigger.yml action


With the change to use https://github.com/CircleCI-Public/trigger-circleci-pipeline-action we will be triggering a workflow (below) and then passing the make target as a job parameter, rather than pipeline parameter. So here we remove this.

psobolewskiPhD · 2025-05-28T01:37:15Z

.circleci/config.yml

+    when:
+      not: << pipeline.parameters.GHA_Meta >>


This change is needed to prevent double-triggers. We want the normal workflow to trigger on push/commit/PR status only, not when the comment/trigger is used.

psobolewskiPhD · 2025-05-28T01:39:22Z

.circleci/config.yml

    jobs:
      - build-docs
+  # triggered by comment to PR with make target
+  triggered-by-issue-comment:


So now for the triggered job, we use a new workflow that checks the GHA_Meta pipeline parameter and kicks off our build-docs job with the right job parameter.

psobolewskiPhD · 2025-05-28T01:41:30Z

.github/workflows/build_docs.yml

  workflow_call:
    inputs:
      make_target:
        description: "Enter make target: html html-noplot docs slimfast slimgallery"
        type: string
-        default: 'slimfast'
+        default: "slimfast"
+      pr_ref:


Add another input parameter so that we can pass the PR detail from the triggering job.

psobolewskiPhD · 2025-05-28T01:45:00Z

.github/workflows/build_docs.yml

@@ -33,6 +37,7 @@ jobs:
        with:
          # Check out to  '/home/runner/work/docs/docs/docs'
          path: docs
+          ref: ${{ inputs.pr_ref || github.ref }}


Here make sure to be able to use the branch info passed in from the triggering job or just the regular dispatch.

psobolewskiPhD · 2025-05-28T01:46:21Z

.github/workflows/build_docs.yml

@@ -70,7 +75,7 @@ jobs:
          GOOGLE_CALENDAR_API_KEY: ${{ secrets.GOOGLE_CALENDAR_API_KEY }}
          PIP_CONSTRAINT: ${{ github.workspace }}/napari/resources/constraints/constraints_py3.10_docs.txt
        with:
-          run:  make -C docs ${{ github.event_name == 'pull_request' && 'slimfast' || inputs.make_target }}
+          run: make -C docs ${{ inputs.make_target || 'slimfast' }}


Make sure the trigger works for both PR triggers and manual dispatch (both use inputs.make_target)

psobolewskiPhD · 2025-05-28T01:47:30Z

.github/workflows/triggered_target_build.yml

+      target: ${{ steps.determine-make-target.outputs.target }}
+      pr_ref: ${{ steps.get-pr-info.outputs.pr_ref }}
+      pr_sha: ${{ steps.get-pr-info.outputs.pr_sha }}


These are the 3 key things we need to know about the trigger:

what make target

pr details, so we can get the right stuff to build and then report back to the right status.

psobolewskiPhD · 2025-05-28T01:49:00Z

.github/workflows/triggered_target_build.yml

+          GHA_Meta: ${{ needs.determine-make-target.outputs.target }}
+          target-branch: ${{ needs.determine-make-target.outputs.pr_ref || github.ref_name }}


Here we pass in the make target from the earlier job and then ensure that status reporting works by also passing in the branch information. If a manual dispatch is used, it will also work (GitHub.ref_name).

psobolewskiPhD · 2025-05-28T01:49:20Z

.github/workflows/triggered_target_build.yml

+    uses: ./.github/workflows/build_docs.yml
+    with:
+      make_target: ${{ needs.determine-make-target.outputs.target }}
+      pr_ref: ${{ needs.determine-make-target.outputs.pr_ref || github.ref_name }}


Again, this is the branch info we need to build the right stuff.

psobolewskiPhD · 2025-05-28T01:50:52Z

.github/workflows/triggered_target_build.yml

+          sha: ${{ needs.determine-make-target.outputs.pr_sha }}
+          token: ${{ secrets.GITHUB_TOKEN }}
+          status: ${{ needs.trigger-artifact-build.result }}
+          context: "Docs Artifact Build: ${{ needs.determine-make-target.outputs.target }}"
+          description: ${{ needs.trigger-artifact-build.result == 'success' && 'Documentation built successfully' || 'Documentation build failed' }}
+          targetUrl: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}


Here's the reporting. We have the right PR info, so then we collect the pass/fail status and the make target so we can put that in the PR status.

TimMonko · 2025-05-29T15:23:36Z

@psobolewskiPhD
Great work! Your github code commenting is beautiful. Exemplified exactly the value we talked about at the last docs meeting!
Can we test in this branch? Or only after merge? I think if I'm reading workflow file, bot should work on this PR?

TimMonko · 2025-05-29T15:25:11Z

@napari-bot make slimfast

TimMonko · 2025-05-29T15:29:05Z

My comment above did trigger an action, but does not add the eyes at the time I expected, which would be at the start of the action.

TimMonko · 2025-05-29T15:38:09Z

Ah, not quite fully hooked up correctly yet:
https://github.com/napari/docs/actions/runs/15327362311?pr=723+%28comment%29

.

psobolewskiPhD · 2025-05-29T16:06:59Z

@TimMonko this repo (napari/docs) is using the actions from the default branch (main), so your comment is using the not-correct original implementation.
If you want to test, as I noted in the PR description, I've made this PR branch the default branch of my fork--equivalent to merging it into main here in the docs repo. You can open a PR in my fork against the the fix_comment_trigger default branch to test. I've opened a PR against that branch in my fork and there you can test this, which i did put in the OP: psobolewskiPhD#90

(it was these branch complications that led my original attempt astray, as can be seen by the needed changes)

TimMonko · 2025-05-29T16:12:53Z

Somehow I didn't put it all together reading your (excellent) PR description. Thank you for the clarification!
Most recently we've been setting up action chagnes to work within the given PR, so I naively thought the same would work here. I guess the reference to main makes this a bit more challenging.

Thanks!

psobolewskiPhD · 2025-05-29T16:13:30Z

Ah, not quite fully hooked up correctly yet: napari/docs/actions/runs/15327362311?pr=723+%28comment%29

If you click to this run, on the left you can click workflow file and see that it's the workflow from main

psobolewskiPhD · 2025-05-29T16:16:57Z

Most recently we've been setting up action chagnes to work within the given PR, so I naively thought the same would work here.

That can work if the action is triggered by PR push for example. But in this case, the triggers are not from the branch of the PR, but from an outside context (comment, label, etc.), which lives in the default branch of the repo.

TimMonko · 2025-05-29T16:21:05Z

Thank you for the extra clarification! Really helping me to learn. The very reason workflow ran from main was why I was concerned, but I now realize how this 'outside context' makes this the issue, and why it is a challenge to troubleshoot this type of CI.

psobolewskiPhD added 25 commits May 26, 2025 12:18

add label-triggered action

7613011

modify the .circleci/config.yml to be able to use triggers

7fc7aeb

add name and tweak the if to be more permissive?

d7a0e35

remove paths trigger.

eb6f374

use latest version of the action explicitly

e9beb41

try to fix passing the paramter to the job

86f1bb2

use the pipeline parameter

c1ba8a9

use a job parameter instead of pipeline parameter

4ab5f0a

ensure we don't double trigger

29c189d

add building artifact

fe56735

Properly trigger the reusable workflow.

dc0aeff

fix build_docs make target input logic -- make it simpler

f678790

simplify comment action and use job parameters to trigger

fa8a42b

fix rename?

1892c50

get and use PR info, add eyes reaction from napari/napari

721624a

use target-branch to get circle to use the PR branch

0593e38

try to fix eyes reaction

45a0a46

fix permissions for the eyes reaction

2ed78de

try a simple status check build artifact

0374d48

fix permission for the status

8ff250a

fix targetUrl

5d6f2cf

avoid status on unrelated comment

d1ac3fd

ensure manual dispatch reports status

b19180f

Only trigger status on comment, add some comments.

3c9093e

update comments and have the status message include the make target

a4af8ac

github-actions bot assigned psobolewskiPhD May 28, 2025

github-actions bot added the maintenance CI, dependencies, and other maintenance label May 28, 2025

psobolewskiPhD added the bug Something isn't working label May 28, 2025

psobolewskiPhD commented May 28, 2025

View reviewed changes

adress Action Lint by using env var

8d98811

psobolewskiPhD added this to the 0.6.2 milestone May 28, 2025

TimMonko previously approved these changes May 29, 2025

View reviewed changes

TimMonko approved these changes May 29, 2025

View reviewed changes

TimMonko added the ready to merge label May 29, 2025

		GHA_Meta: ${{ needs.determine-make-target.outputs.target }}
		target-branch: ${{ needs.determine-make-target.outputs.pr_ref \|\| github.ref_name }}

Fix comment and manual dispatch triggered build jobs #723

Are you sure you want to change the base?

Fix comment and manual dispatch triggered build jobs #723

Uh oh!

Conversation

psobolewskiPhD commented May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

References and relevant issues

Description

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TimMonko commented May 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TimMonko commented May 29, 2025

Uh oh!

TimMonko commented May 29, 2025

Uh oh!

TimMonko commented May 29, 2025

Uh oh!

psobolewskiPhD commented May 29, 2025

Uh oh!

TimMonko commented May 29, 2025

Uh oh!

psobolewskiPhD commented May 29, 2025

Uh oh!

psobolewskiPhD commented May 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TimMonko commented May 29, 2025

Uh oh!

Uh oh!

psobolewskiPhD commented May 28, 2025 •

edited

Loading

TimMonko commented May 29, 2025 •

edited

Loading

psobolewskiPhD commented May 29, 2025 •

edited

Loading