Skip to content

Fix comment and manual dispatch triggered build jobs #723

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 29 commits into from
Jun 18, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
29 commits
Select commit Hold shift + click to select a range
7613011
add label-triggered action
psobolewskiPhD May 26, 2025
7fc7aeb
modify the .circleci/config.yml to be able to use triggers
psobolewskiPhD May 26, 2025
d7a0e35
add name and tweak the if to be more permissive?
psobolewskiPhD May 26, 2025
eb6f374
remove paths trigger.
psobolewskiPhD May 26, 2025
e9beb41
use latest version of the action explicitly
psobolewskiPhD May 26, 2025
86f1bb2
try to fix passing the paramter to the job
psobolewskiPhD May 26, 2025
c1ba8a9
use the pipeline parameter
psobolewskiPhD May 26, 2025
4ab5f0a
use a job parameter instead of pipeline parameter
psobolewskiPhD May 26, 2025
29c189d
ensure we don't double trigger
psobolewskiPhD May 26, 2025
fe56735
add building artifact
psobolewskiPhD May 26, 2025
dc0aeff
Properly trigger the reusable workflow.
psobolewskiPhD May 26, 2025
f678790
fix build_docs make target input logic -- make it simpler
psobolewskiPhD May 26, 2025
fa8a42b
simplify comment action and use job parameters to trigger
psobolewskiPhD May 26, 2025
1892c50
fix rename?
psobolewskiPhD May 26, 2025
721624a
get and use PR info, add eyes reaction from napari/napari
psobolewskiPhD May 26, 2025
0593e38
use target-branch to get circle to use the PR branch
psobolewskiPhD May 26, 2025
45a0a46
try to fix eyes reaction
psobolewskiPhD May 26, 2025
2ed78de
fix permissions for the eyes reaction
psobolewskiPhD May 26, 2025
0374d48
try a simple status check build artifact
psobolewskiPhD May 26, 2025
8ff250a
fix permission for the status
psobolewskiPhD May 27, 2025
5d6f2cf
fix targetUrl
psobolewskiPhD May 27, 2025
d1ac3fd
avoid status on unrelated comment
psobolewskiPhD May 27, 2025
b19180f
ensure manual dispatch reports status
psobolewskiPhD May 27, 2025
3c9093e
Only trigger status on comment, add some comments.
psobolewskiPhD May 27, 2025
a4af8ac
update comments and have the status message include the make target
psobolewskiPhD May 27, 2025
8d98811
adress Action Lint by using env var
psobolewskiPhD May 28, 2025
d0c6bb7
Apply suggestions from code review by Carol
psobolewskiPhD Jun 6, 2025
5613492
clarify the build-docs workflow when condition (comment)
psobolewskiPhD Jun 6, 2025
8f43c20
Add additional comments to the triggered_target_build workflow and ci…
psobolewskiPhD Jun 6, 2025
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 45 additions & 7 deletions .circleci/config.yml
Original file line number Diff line number Diff line change
Expand Up @@ -6,21 +6,40 @@
# Check for more details: https://circleci.com/docs/2.1/configuration-reference
version: 2.1

# in addition to the default circleCI triggering, we have a GitHub Action:
# .github/triggered_target_build.yml
# This Action has a job that uses CircleCI-Public/trigger-circleci-pipeline-action.
# This allows triggering a CircleCI pipeline from any event on GitHub with GitHub Actions.
# Right now we are using comments on PRs to trigger the workflow "triggered-by-pr-comment"
# See: https://github.com/CircleCI-Public/trigger-circleci-pipeline-action/blob/main/README.md
parameters:
GHA_Actor:
type: string
default: ""
GHA_Action:
type: string
default: ""
GHA_Event:
type: string
default: ""
GHA_Meta:
type: string
default: ""

# 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/[email protected]

# parameterize the make target used for build, passed in from build_trigger.yml action
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

parameters:
make_target:
type: string
default: "slimfast"

jobs:
build-docs:
docker:
- image: cimg/python:3.10.17
parameters:
# Set make target for the job
make_target:
type: string
default: slimfast
steps:
- checkout:
path: docs
Expand All @@ -47,7 +66,7 @@ jobs:
command: |
. .venv/bin/activate
cd docs
xvfb-run --auto-servernum make << pipeline.parameters.make_target >>
xvfb-run --auto-servernum make << parameters.make_target >>
environment:
PIP_CONSTRAINT: ../napari/resources/constraints/constraints_py3.10_docs.txt
- store_artifacts:
Expand All @@ -58,5 +77,24 @@ jobs:
- docs/docs/_build/html/
workflows:
build-docs:
# this workflow is triggered automatically by default
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I see what is confusing now. This wording is fine now. I do think that we should add to the top of this file the following:

# This GitHub Action workflow uses CircleCI-Public/trigger-circleci-pipeline-action.
# This allows triggering a CircleCI pipeline from any event on GitHub with GitHub Actions.
# See: https://github.com/CircleCI-Public/trigger-circleci-pipeline-action/blob/main/README.md

# so we want to prevent it from triggering when triggering
# via CircleCI-Public/trigger-circleci-pipeline-action
# which always passes the GHA_Meta parameter
# this prevents double triggers
when:
not: << pipeline.parameters.GHA_Meta >>
Comment on lines +85 to +86
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

jobs:
- build-docs
# Run this workflow when a PR comment triggers a docs build for `make` target
triggered-by-pr-comment:
when:
or:
- equal: ["slimfast", << pipeline.parameters.GHA_Meta >>]
- equal: ["slimgallery", << pipeline.parameters.GHA_Meta >>]
- equal: ["docs", << pipeline.parameters.GHA_Meta >>]
- equal: ["html", << pipeline.parameters.GHA_Meta >>]
- equal: ["html-noplot", << pipeline.parameters.GHA_Meta >>]
jobs:
- build-docs:
make_target: << pipeline.parameters.GHA_Meta >>
13 changes: 9 additions & 4 deletions .github/workflows/build_docs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -5,19 +5,23 @@ name: Build PR Docs
on:
pull_request:
branches:
- main
- main
workflow_dispatch:
inputs:
make_target:
description: "Enter make target: html html-noplot docs slimfast slimgallery"
type: string
default: 'slimfast'
default: "slimfast"
workflow_call:
inputs:
make_target:
description: "Enter make target: html html-noplot docs slimfast slimgallery"
type: string
default: 'slimfast'
default: "slimfast"
pr_ref:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pr_ref or pr_branch?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

um, good question. let me try to look that up again. I think it's correct, but it's been a while since I looked at this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so this is analogous to the github.ref that would be normally used, which is using the git terminology. So i lean to keeping this the same, because it will make it easier for anyone diving into this, but keeping things consistent?

description: "PR branch reference"
type: string
required: false

concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
Expand All @@ -33,6 +37,7 @@ jobs:
with:
# Check out to '/home/runner/work/docs/docs/docs'
path: docs
ref: ${{ inputs.pr_ref || github.ref }}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adding branch to pr_ref name would improve readability and clarity (or renaming to pr_branch)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If i recall ref is the GitHub terminology. I will try to circle around to this and see if it can be changed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, as noted in the other spot, ref is actually git terminology and it is also used by GitHub. So we either use the github.ref if using a workflow dispatch or the pr...ref which we have stored in the pr_ref variable. So i lean to leaving this to make it easier for someone searching/reading github/git docs to sort this out?


- name: Clone main repo
uses: actions/checkout@v4
Expand Down Expand Up @@ -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' }}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

# skipping setup stops the action from running the default (tiling) window manager
# the window manager is not necessary for docs builds at this time and it was causing
# problems with screenshots (https://github.com/napari/docs/issues/285)
Expand Down
141 changes: 0 additions & 141 deletions .github/workflows/build_trigger.yml

This file was deleted.

121 changes: 121 additions & 0 deletions .github/workflows/triggered_target_build.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,121 @@
name: Trigger target build of docs
# This workflow can be started either by commenting on a pull request or by using workflow_dispatch manually.
# You can specify a `make` target to build the documentation for a specific branch or pull request.
# If started by a comment, the workflow runs on the PR branch and updates the PR status.
# Note: This workflow runs only once per trigger and does not execute on every push to the PR branch.
# This workflow triggers both the CircleCI doc build, using CircleCI-Public/trigger-circleci-pipeline-action.
# as well as an artifact build using the reusable workflow: .github/build_docs.yml

on:
issue_comment:
types: [created]
workflow_dispatch:
inputs:
make_target:
description: "Enter make target: html html-noplot docs slimfast slimgallery"
type: string
default: "slimfast"

permissions:
contents: read
issues: write
pull-requests: write
statuses: write

jobs:
determine-make-target:
runs-on: ubuntu-latest
outputs:
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 }}
Comment on lines +29 to +31
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

if: |
(github.event_name == 'issue_comment' &&
github.event.issue.pull_request != '' &&
contains(github.event.comment.body, '@napari-bot make')) ||
github.event_name == 'workflow_dispatch'
steps:
- name: Add eyes reaction
# If triggered by comment, show that workflow has started
if: github.event_name == 'issue_comment'
uses: actions/github-script@v7
with:
script: |
await github.rest.reactions.createForIssueComment({
owner: context.repo.owner,
repo: context.repo.repo,
comment_id: context.payload.comment.id,
content: 'eyes'
});

- name: Determine make target from comment or input
id: determine-make-target
env:
COMMENT_BODY: ${{ github.event.comment.body }}
run: |
ALLOWED_TARGETS="html html-noplot docs slimfast slimgallery"

if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
TARGET="${{ github.event.inputs.make_target }}"
else
TARGET=$(echo "$COMMENT_BODY" | grep -oP '(?<=@napari-bot make\s)\w+' || echo "slimfast")
fi

if ! echo "$ALLOWED_TARGETS" | grep -qw "$TARGET"; then
echo "::error::Invalid target '$TARGET'. Allowed: $ALLOWED_TARGETS"
exit 1
fi

echo "target=$TARGET" >> "$GITHUB_OUTPUT"

- name: Get PR details
# issue_comment is run from the main branch context so
# extract PR number and branch name from issue_comment event
if: github.event_name == 'issue_comment'
id: get-pr-info
uses: actions/github-script@v7
with:
script: |
const pr = await github.rest.pulls.get({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.issue.number
});
core.setOutput('pr_ref', pr.data.head.ref);
core.setOutput('pr_sha', pr.data.head.sha);

trigger-circleci:
needs: determine-make-target
runs-on: ubuntu-latest
steps:
- name: Run CircleCI pipeline
uses: CircleCI-Public/[email protected]
with:
GHA_Meta: ${{ needs.determine-make-target.outputs.target }}
target-branch: ${{ needs.determine-make-target.outputs.pr_ref || github.ref_name }}
Comment on lines +94 to +95
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

env:
CCI_TOKEN: ${{ secrets.CIRCLECI_TOKEN }}

trigger-artifact-build:
needs: determine-make-target
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 }}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


report-artifact-status:
# reusable workflows can't be a step in a job
# so to get the status of the artifact build, we need a separate job
needs: [determine-make-target, trigger-artifact-build]
runs-on: ubuntu-latest
if: always() && github.event_name == 'issue_comment' && needs.trigger-artifact-build.result != 'skipped'
steps:
- name: Set build job status
uses: myrotvorets/set-commit-status-action@master
with:
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 }}
Comment on lines +116 to +121
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.