chore(workflow): pin bonedigger lifecycle to clanker-queue rollout - #1196
chore(workflow): pin bonedigger lifecycle to clanker-queue rollout#1196castrojo wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughThe lifecycle job’s reusable workflow reference is updated from the previous pinned revision to commit ChangesLifecycle workflow update
Estimated code review effort: 1 (Trivial) | ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
This PR targets |
hanthor
left a comment
hanthor
left a comment
There was a problem hiding this comment.
This one-line rollout change targets main from a branch based on the active testing line, so the PR currently contains a large set of unrelated workflow, element, patch, and documentation changes and is conflicting. Dakota content PRs must target testing. Please retarget or recreate it from testing with only the bonedigger pin, then refresh that pin after the blocking changes on projectbluefin/bonedigger#33 are resolved.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
036f52b to
6f2efdc
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/bonedigger.yml:
- Around line 20-23: Remove the `secrets: inherit` entry from the reusable
workflow invocation in the Bonedigger workflow, leaving `uses` and `brand_name`
unchanged so the called workflow relies on its automatically provided
`github.token`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: fd67166d-35f4-4056-95f2-b4a89d44a906
📒 Files selected for processing (1)
.github/workflows/bonedigger.yml
| uses: projectbluefin/bonedigger/.github/workflows/lifecycle.yml@aa3185566171de43106976cd5a0ac72ee3106868 # clanker-queue-rollout | ||
| with: | ||
| brand_name: "Dakota" | ||
| secrets: inherit |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow snippets =="
if [ -f .github/workflows/bonedigger.yml ]; then
nl -ba .github/workflows/bonedigger.yml | sed -n '1,80p'
else
echo ".github/workflows/bonedigger.yml not found"
fi
echo
echo "== reusable workflow source from pinned SHA =="
python3 - <<'PY'
import urllib.request
url="https://raw.githubusercontent.com/projectbluefin/bonedigger/aa3185566171de43106976cd5a0ac72ee3106868/.github/workflows/lifecycle.yml"
try:
text=urllib.request.urlopen(url, timeout=20).read().decode()
for i,line in enumerate(text.splitlines(), 1):
print(f"{i:4}: {line}")
except Exception as e:
print(f"ERROR fetching {url}: {e}")
PY
echo
echo "== other secrets inheritance usages in workflows =="
rg -n "secrets:\s*inherit|secrets:\s*\{" .github/workflows || trueRepository: projectbluefin/dakota
Length of output: 223
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow snippets =="
if [ -f .github/workflows/bonedigger.yml ]; then
sed -n '1,100p' .github/workflows/bonedigger.yml | cat -n
else
echo ".github/workflows/bonedigger.yml not found"
fi
echo
echo "== reusable workflow source from pinned SHA =="
python3 - <<'PY'
import urllib.request
url="https://raw.githubusercontent.com/projectbluefin/bonedigger/aa3185566171de43106976cd5a0ac72ee3106868/.github/workflows/lifecycle.yml"
try:
text=urllib.request.urlopen(url, timeout=20).read().decode()
lines=text.splitlines()
for i,line in enumerate(lines, 1):
print(f"{i:4}: {line}")
print(f"\nTOKEN usages: {[i for i,line in enumerate(lines,1) if 'secrets.GITHUB_TOKEN' in line or 'GITHUB_TOKEN' in line][:20]}")
except Exception as e:
print(f"ERROR fetching {url}: {e}")
PY
echo
echo "== other secrets inheritance usages in workflows =="
rg -n "secrets:\s*inherit|secrets:\s*\{" .github/workflows || true
echo
echo "== files in .github/workflows =="
git ls-files .github/workflowsRepository: projectbluefin/dakota
Length of output: 2455
🌐 Web query:
GitHub Actions reusable workflows permissions GITHUB_TOKEN automatically available secrets GitHub Actions documentation
💡 Result:
In GitHub Actions, reusable workflows handle permissions and secrets differently, as detailed below: GITHUB_TOKEN and Permissions The GITHUB_TOKEN is automatically available to reusable workflows [1][2]. Regarding permissions, reusable workflows inherit the permissions configured in the job that calls them [1][2]. If no permissions are explicitly specified in the calling job, the called workflow defaults to the standard default permissions for the GITHUB_TOKEN [1][2]. Crucially, GITHUB_TOKEN permissions passed to or inherited by a reusable workflow can only be restricted (downgraded) and never elevated; this applies to entire chains of nested workflows [1][2]. Secrets Unlike the GITHUB_TOKEN, other secrets are not automatically passed to reusable workflows [3][4]. To make secrets available, you must explicitly pass them using one of two methods [5]: 1. Explicit Passing: You can define the secrets in the reusable workflow's on.workflow_call block and pass them from the calling workflow using the secrets keyword [6][7][5]. 2. Inheritance: You can use the secrets: inherit keyword in the calling workflow to automatically pass all repository and organization secrets from the caller to the reusable workflow [6][7][5]. Note that environment secrets cannot be passed to reusable workflows because on.workflow_call does not support the environment keyword [6][7]. If a reusable workflow specifies an environment at the job level, it will use that environment's secrets rather than any secrets passed from the caller [6][7].
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/reusing-workflow-configurations
- 2: https://docs.github.com/en/enterprise-server@3.13/actions/reference/reusable-workflows-reference
- 3: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets
- 4: https://docs.github.com/actions/security-guides/using-secrets-in-github-actions
- 5: https://rtfm.co.ua/en/github-actions-working-with-reusable-workflows/
- 6: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 7: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
🌐 Web query:
site:raw.githubusercontent.com/projectbluefin/bonedigger aa3185566171de43106976cdaa3185566171de43106976cd5a0ac72ee3106868 .github/workflows/lifecycle.yml
💡 Result:
I couldn’t verify that exact raw.githubusercontent.com/projectbluefin/bonedigger/.../.github/workflows/lifecycle.yml path. What I found instead is that Bluefin’s docs and reports discuss a bonedigger lifecycle workflow, but the reusable lifecycle.yml appears to live in projectbluefin/common, not directly in bonedigger. The docs also note that bonedigger was pinned to a SHA and later had to be updated because the pinned commit predated lifecycle.yml in that repo. (app.dosu.dev)
If you want, I can help locate the exact raw file URL or the commit SHA that contains it.
Citations:
🌐 Web query:
projectbluefin bonedigger lifecyle.yml secrets.GITHUB_TOKEN projectbluefin/common workflow_call inputs
💡 Result:
In the Project Bluefin ecosystem, bonedigger and common handle separate, complementary parts of the issue lifecycle automation [1][2][3]. The bonedigger repository provides a specialized workflow, lifecycle.yml, which handles: - Detecting ujust report issue bodies [3][4]. - Syncing priority labels based on ujust confirm counts (e.g., 3+ for priority/p1, 5+ for priority/p0) [2][4]. - Managing agent donation fast-track labels [2][3]. The broader issue lifecycle management, previously handled by bonedigger, was moved to projectbluefin/common/.github/workflows/lifecycle.yml [1][2]. This common workflow manages [4]: - Slash commands (e.g., /claim, /approve, /lgtm, /wontfix, /hold) [1][4]. - Issue body widget rendering (the pipeline status block) [1][4]. - Label creation and synchronization [1][4]. - Stale issue sweeps (queue transitions) [1][4]. Configuration: - Repositories typically call the bonedigger lifecycle workflow via uses: projectbluefin/bonedigger/.github/workflows/lifecycle.yml@main [2][3]. - If a repository requires the full set of lifecycle features, it must also wire the caller for projectbluefin/common/.github/workflows/lifecycle.yml [2][3]. - Regarding secrets.GITHUB_TOKEN: Project Bluefin workflows have transitioned away from requiring secrets: inherit for GITHUB_TOKEN usage [5][6]. Reusable workflows now prioritize using the automatically available github.token directly, and maintainers have explicitly removed empty secrets blocks and secrets: inherit lines from callers to improve security and satisfy workflow_call requirements [7][6]. Inputs: - When using workflow_call, workflows expect specific inputs defined in their respective on.workflow_call.inputs blocks [8][9][10]. For example, reusable-build.yml requires inputs like brand_name and stream_name [8][11], while ISO build workflows require inputs like image_version [9][10]. Documentation for these inputs is typically found within the specific reusable workflow file or the project's docs/skills/ directory [8][11][10].
Citations:
- 1: https://github.com/projectbluefin/bonedigger/blob/main/docs/skills/bonedigger-lifecycle.md
- 2: https://github.com/projectbluefin/bonedigger
- 3: https://github.com/projectbluefin/bonedigger/blob/main/docs/skills/bonedigger-overview.md
- 4: https://github.com/projectbluefin/common/blob/main/docs/skills/label-workflow.md
- 5: projectbluefin/actions@beb89cf
- 6: projectbluefin/actions@d290241
- 7: fix(ci): bump lifecycle-caller SHA to actions v1 HEAD common#712
- 8: https://github.com/projectbluefin/actions/blob/main/.github/workflows/reusable-build.yml
- 9: feat: split ISO builds into independent workflows with monthly scheduling iso#3
- 10: https://github.com/projectbluefin/iso/blob/7d4011a533c5e109b3d6e6f4cbe1cb456826e6fb/.github/workflows/reusable-build-iso-anaconda.yml
- 11: https://github.com/projectbluefin/bluefin-lts/blob/main/docs/skills/ci-cd.md
🏁 Script executed:
#!/bin/bash
set -u
echo "== git config =="
git config --get remote.origin.url || true
git rev-parse --is-inside-work-tree || true
echo
echo "== GitHub API pinned ref/tags/commit =="
python3 - <<'PY'
import json, urllib.request
owner,repo="projectbluefin","bonedigger"
sha="aa3185566171de43106976cd5a0ac72ee3106868"
base=f"https://api.github.com/repos/{owner}/{repo}"
print("git ref:")
try:
print(
urllib.request.urlopen(f"{base}/git/refs/tags/{sha.split('# ')[0]}", timeout=20).read().decode()
)
except Exception as e:
print(f"TAG_REF_ERROR: {type(e).__name__}: {e}")
print("\nresolved commit object:")
try:
text=urllib.request.urlopen(f"{base}/git/commits/{sha}", timeout=20).read().decode()
data=json.loads(text)
print({k:data.get(k) for k in ("sha","type","message")})
except Exception as e:
print(f"COMMIT_ERROR: {type(e).__name__}: {e}")
print("\nraw workflow from pinned valid commit:")
url=f"https://raw.githubusercontent.com/{owner}/{repo}/{sha}/.github/workflows/lifecycle.yml"
try:
import ssl
ctx=ssl.create_default_context()
raw=urllib.request.urlopen(url, timeout=20, context=ctx).read().decode()
lines=raw.splitlines()
for i,line in enumerate(lines,1):
if i<=120:
print(f"{i:4}: {line}")
print(f"\nsecret/token/permission-related lines:")
for i,line in enumerate(lines,1):
if any(k in line for k in ("secrets.", "permissions", "workflow_call", "github.token", "repo", "repo:")):
print(f"{i:4}: {line}")
except Exception as e:
print(f"RAW_ERROR: {type(e).__name__}: {e}")
PYRepository: projectbluefin/dakota
Length of output: 813
🌐 Web query:
site:raw.githubusercontent.com/projectbluefin/bonedigger aa3185566171de43106976cd5a0ac72ee3106868 .github/workflows/lifecycle.yml secrets.GITHUB_TOKEN
💡 Result:
Yes — that workflow uses secrets.GITHUB_TOKEN as GH_TOKEN in multiple steps, including issue view/edit operations. (raw.githubusercontent.com)
Citations:
Avoid inheriting all caller secrets.
This reusable workflow consumes secrets.GITHUB_TOKEN, which reusable workflows receive automatically via github.token, so secrets: inherit unnecessarily exposes all Dakota caller secrets to the called workflow. Remove that line unless a specific additional secret is required.
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 20-20: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow
(secrets-inherit)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/bonedigger.yml around lines 20 - 23, Remove the `secrets:
inherit` entry from the reusable workflow invocation in the Bonedigger workflow,
leaving `uses` and `brand_name` unchanged so the called workflow relies on its
automatically provided `github.token`.
Source: Linters/SAST tools
|
Merged into testing in commit a2feac9. |
Pull request was closed
castrojo
added
4-review
2 participants
Pins dakota's bonedigger caller to the new bonedigger rollout SHA so it can consume the clanker-queue migration workflow.
Summary by CodeRabbit