Skip to content

Stop dispatching Build libheif from the release check - #4

Merged
jakejackson1 merged 1 commit into
mainfrom
ci/drop-build-dispatch
Sep 17, 2026
Merged

jakejackson1 merged 1 commit into
mainfrom
ci/drop-build-dispatch

Conversation

@jakejackson1

Copy link
Copy Markdown
Member

Follow-up to #2, based on the end-to-end test in #3.

What the test showed

update-libheif.yml dispatched Build libheif on each PR branch because I'd assumed a PR opened with GITHUB_TOKEN doesn't trigger pull_request workflows. It does. GitHub creates the run and holds it as action required until a maintainer approves it.

On #3 that caused two problems:

  • The pending pull_request run is what the PR's checks show. It has the same job name as the dispatched run, so the dispatched run's success was never visible on the PR.
  • Each update ran the ~17-minute build twice once the pending run was approved.

Changes

  • Remove gh workflow run build-libheif.yml and the actions: write permission it needed.
  • The bot's PR description and its Slack message now say to approve the pending Build libheif run.
  • Correct the header comments in both workflows.

actionlint passes. The update flow is otherwise unchanged from the tested run.

🤖 Generated with Claude Code

A PR opened with GITHUB_TOKEN does create a pull_request run; it waits for
maintainer approval. That pending run is what the PR's checks show, so the
dispatched run's result was never visible and each update built twice.
Point the PR description and Slack message at approving the run instead,
and drop the actions: write permission the dispatch needed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jakejackson1
jakejackson1 merged commit 0797133 into main Sep 17, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant