Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

fix(ci): cancel the dependabot-fragments run stuck waiting on plugin-release since 2026-10-10

Open Beginner friendly
  • Is something wrong?
#7,925 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
92/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, shell
Domain
ci-cd, release

Research direction

Start with .github/workflows/dependabot-fragments.yml, especially the concurrency and fragment-generation steps, and compare the waiting run with the successful release-publish-plugins.yml workflow. Cancel run 38093644200 with the documented gh or GitHub API command, then confirm no dependabot-fragments run remains waiting. Done means the next scheduled or push run succeeds and opens or updates release/dependabot-fragments, or logs that no fragments are pending.

Written by the indexing model from the issue text.

Description

needs-human

No related issue: found by the monitoring session

Summary

One dependabot-fragments run, 38093644200 (push, 2026-10-10T23:02Z, head 786dd9a9), has sat in waiting on the plugin-release environment for seven days. It holds the workflow's concurrency group, so every later run waits behind it as pending and is cancelled when the next one arrives. 500 of the 501 runs in the last 7 days ended cancelled (330 on push, 170 scheduled), and none of them got a job (/actions/runs/39091122869/jobs is empty). The last successful run was 38092025605 on 2026-10-10T22:35Z.

Evidence:

  • .github/workflows/dependabot-fragments.yml:32-34: concurrency: group: dependabot-fragments, cancel-in-progress: false, set at the workflow level, so a run that is waiting on its environment holds the group.
  • GET /actions/runs/38093644200/pending_deployments: environment plugin-release, reviewers: [], wait_timer: 0, current_user_can_approve: false. The environment has only a branch_policy rule. There is nothing to approve, yet the run stays waiting. It is the only waiting run in the repository.
  • The same environment passes for release-publish-plugins.yml (its runs on 2026-10-18 succeed), so the environment itself does not block. The likely trigger is github-iac#633 (2026-10-10T14:55Z, "disable admin bypass on the plugin-release environment"), but that link is UNVERIFIED.
  • GitHub concurrency docs (https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency): "When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be pending. By default, any existing pending job or workflow in the same concurrency group will be canceled and the new queued job or workflow will take its place."

Impact: no changelog fragment has been written for any Dependabot merge since 2026-10-10. The search API returns 19 merged Dependabot PRs for that window (for example #7706, #7707, #7708); the ones that touch fragment-mode plugins have no fragment, so the release PR leaves those bumps out. No runner minutes are wasted, because the cancelled runs never started a job. The cost is the missing fragments.

Fix

  1. Cancel the stuck run: gh run cancel 38093644200 -R melodic-software/claude-code-plugins, or, if it stays waiting, POST /repos/melodic-software/claude-code-plugins/actions/runs/38093644200/force-cancel. The run never reached a step, so the workflow's concern about cancelling after the force-reset (lines 28-31) does not apply. The next push or the :23 schedule then runs from main and writes every missing fragment, because fragments are named by merge commit (line 16-17).
  2. No workflow change is needed for this incident. Revisit only if a run sticks again.

Verification

  • gh api repos/melodic-software/claude-code-plugins/actions/runs?status=waiting returns no dependabot-fragments run.
  • The next dependabot-fragments run ends success, and either opens or updates release/dependabot-fragments with the missing fragments, or logs that none are pending.

Related

  • #5786 (why Dependabot PRs carry no fragment)
  • ADR 0048 (docs/adr/0048-release-plugins-from-changelog-fragments-through-a-bot-maintained-release-pr.md)

🤖 Generated with Claude Code

https://claude.ai/code/session_01PfAeL8XHnWAexMLmaSzZZH

Dominant language
Shell
Stars
22
Forks
2
Avg merge
7h 8m
Merged PRs (30d)
874

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from melodic-software/claude-code-plugins

All issues in melodic-software/claude-code-plugins

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.