feat(hive): add bonedigger lifecycle bot and hive-status-sync#391
feat(hive): add bonedigger lifecycle bot and hive-status-sync#391castrojo wants to merge 1 commit into
Conversation
Onboards projectbluefin/common into the hive agent workflow. - bonedigger.yml: reusable lifecycle bot (/claim /unclaim /approve) with Common ⚙️ branding. Auto-creates queue/agent-ready, queue/claimed, and all lifecycle labels on first run. - hive-status-sync.yml: hourly sync of hive agent formation status to the todo.projectbluefin.io project (PVT_kwDOCCE0ds4BLZBC). Reports common's CI state and issue queue counts. Requires PROJECT_TOKEN secret. Needs: add PROJECT_TOKEN secret to projectbluefin/common, add P0 label. Assisted-by: Claude Sonnet 4.6 via GitHub Copilot CLI
dosubot
Bot
added
size:XS
📝 WalkthroughWalkthroughThis PR adds two new GitHub Actions workflows to the repository. The ChangesBonedigger Issue Lifecycle Workflow
Hive Status Sync Project Updates
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 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:
- Line 17: The workflow currently imports the reusable workflow with the mutable
ref "uses: projectbluefin/bonedigger/.github/workflows/lifecycle.yml@main";
update that ref to a fixed commit SHA or a released tag (e.g., replace "`@main`"
with "@<full-commit-sha>" or "`@vX.Y.Z`") so the reusable workflow import is
pinned and builds are reproducible and auditable.
- Line 21: Replace the broad "secrets: inherit" usage with an explicit secrets
map: determine which repository secrets the reusable workflow actually needs,
remove "secrets: inherit", and add a "secrets:" block that lists each required
secret by name and maps it to the corresponding repository secret (e.g.,
SECRET_NAME: ${{ secrets.SECRET_NAME }}). Update the reusable workflow call site
that currently contains "secrets: inherit" so it only passes those specific
secret keys, ensuring least-privilege access.
In @.github/workflows/hive-status-sync.yml:
- Around line 17-20: The step "Fetch Hive snapshot and post project status"
currently checks for the presence of PROJECT_TOKEN late in the script, after
external snapshot fetches and GH API queries; move that missing-token guard to
the top-level of the step so the whole step is skipped before any run actions
when secrets.PROJECT_TOKEN is absent. Update the step's top-level condition (the
step that declares name: "Fetch Hive snapshot and post project status" and env:
GH_TOKEN) to short-circuit execution if PROJECT_TOKEN is missing, and apply the
same change to the other steps with the same pattern (the blocks around lines
31-40, 103-130, and 224-227) so no network calls or API queries happen when
PROJECT_TOKEN is not provided.
- Around line 114-125: The CI lookup currently grabs the latest workflow run
repo-wide and can pick PR or feature-branch builds; update the gh_json("run",
"list", ...) call that populates ci_runs so it is scoped to the default branch
by adding the branch filter (e.g., --branch main) or equivalent flag, ensuring
ci_runs (and the subsequent run/conclusion/url logic) only considers runs from
main rather than the newest repo-wide run.
- Around line 127-130: count_label() undercounts because gh issue list defaults
to --limit 30; update the gh_json call in count_label to include an explicit
high limit (e.g. add "--limit", "1000") so the full set of open issues for the
given label is returned before taking len(raw); change the call in the
count_label function that invokes gh_json("issue", "list", "--repo", REPO,
"--label", label, "--state", "open", "--json", "number") to include the --limit
argument to prevent truncation.
🪄 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: a05c8b62-5d57-42ec-8d70-5c87cf83984b
📒 Files selected for processing (2)
.github/workflows/bonedigger.yml.github/workflows/hive-status-sync.yml
|
|
||
| jobs: | ||
| bonedigger: | ||
| uses: projectbluefin/bonedigger/.github/workflows/lifecycle.yml@main |
There was a problem hiding this comment.
Pin the reusable workflow to a commit SHA or release tag.
The workflow references @main, which can change without notice. This creates supply chain risk and prevents reproducible builds. Best practice is to pin to a specific commit SHA.
🔒 Recommended fix
- uses: projectbluefin/bonedigger/.github/workflows/lifecycle.yml@main
+ uses: projectbluefin/bonedigger/.github/workflows/lifecycle.yml@<commit-sha>Replace <commit-sha> with the full commit hash from the bonedigger repository's main branch, or use a release tag like @v1.0.0 if available.
🧰 Tools
🪛 zizmor (1.25.2)
[error] 17-17: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[warning] 17-17: 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 at line 17, The workflow currently imports
the reusable workflow with the mutable ref "uses:
projectbluefin/bonedigger/.github/workflows/lifecycle.yml@main"; update that ref
to a fixed commit SHA or a released tag (e.g., replace "`@main`" with
"@<full-commit-sha>" or "`@vX.Y.Z`") so the reusable workflow import is pinned and
builds are reproducible and auditable.
| with: | ||
| brand_name: "Common" | ||
| brand_emoji: "⚙️" | ||
| secrets: inherit |
There was a problem hiding this comment.
Explicitly pass only required secrets instead of inheriting all secrets.
secrets: inherit grants the reusable workflow access to all repository secrets, violating the principle of least privilege. If the external workflow is compromised, all secrets are exposed.
🛡️ Recommended approach
First, verify which secrets the reusable workflow actually requires, then pass them explicitly:
- secrets: inherit
+ secrets:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ # Add other required secrets explicitly📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| secrets: inherit | |
| secrets: | |
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | |
| # Add other required secrets explicitly |
🤖 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 at line 21, Replace the broad "secrets:
inherit" usage with an explicit secrets map: determine which repository secrets
the reusable workflow actually needs, remove "secrets: inherit", and add a
"secrets:" block that lists each required secret by name and maps it to the
corresponding repository secret (e.g., SECRET_NAME: ${{ secrets.SECRET_NAME }}).
Update the reusable workflow call site that currently contains "secrets:
inherit" so it only passes those specific secret keys, ensuring least-privilege
access.
| - name: Fetch Hive snapshot and post project status | ||
| env: | ||
| GH_TOKEN: ${{ secrets.PROJECT_TOKEN }} | ||
| run: | |
There was a problem hiding this comment.
Move the missing-token guard to the top of the step.
This only skips at Line 225, after the workflow has already fetched the external snapshot and queried GitHub. During the documented post-merge window before PROJECT_TOKEN is added, any failure there turns an intended no-op into a red run.
Proposed fix
import re, json, subprocess, urllib.request, sys, os
from datetime import datetime, timezone
+ if not os.environ.get("GH_TOKEN"):
+ print("WARNING: PROJECT_TOKEN secret is not set — skipping project status post", file=sys.stderr)
+ sys.exit(0)
+
SNAPSHOT_URL = "https://raw.githubusercontent.com/kubestellar/docs/main/public/live/hive/bluefin/index.html"
PROJECT_ID = "PVT_kwDOCCE0ds4BLZBC"
DASHBOARD_URL = "https://kubestellar.io/live/hive/bluefin/"
@@
- # Guard: skip posting if PROJECT_TOKEN is not configured
- if not os.environ.get("GH_TOKEN"):
- print("WARNING: PROJECT_TOKEN secret is not set — skipping project status post", file=sys.stderr)
- sys.exit(0)
-
# Post to GitHub Project status updateAlso applies to: 31-40, 103-130, 224-227
🤖 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/hive-status-sync.yml around lines 17 - 20, The step "Fetch
Hive snapshot and post project status" currently checks for the presence of
PROJECT_TOKEN late in the script, after external snapshot fetches and GH API
queries; move that missing-token guard to the top-level of the step so the whole
step is skipped before any run actions when secrets.PROJECT_TOKEN is absent.
Update the step's top-level condition (the step that declares name: "Fetch Hive
snapshot and post project status" and env: GH_TOKEN) to short-circuit execution
if PROJECT_TOKEN is missing, and apply the same change to the other steps with
the same pattern (the blocks around lines 31-40, 103-130, and 224-227) so no
network calls or API queries happen when PROJECT_TOKEN is not provided.
| ci_runs = gh_json("run", "list", "--repo", REPO, "--workflow", "build.yml", | ||
| "--limit", "1", "--json", "conclusion,url") | ||
| if ci_runs: | ||
| run = ci_runs[0] | ||
| conclusion = run.get("conclusion", "") | ||
| url = run.get("url", "") | ||
| if conclusion == "success": | ||
| ci_label = f"[✅ build stable]({url})" | ||
| elif conclusion in ("failure", "startup_failure"): | ||
| ci_label = f"[❌ build degraded]({url})" | ||
| else: | ||
| ci_label = f"[⏳ build running]({url})" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
gh run list --help | sed -n '/--branch/,+2p;/--event/,+2p'Repository: projectbluefin/common
Length of output: 443
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/hive-status-sync.yml"
echo "== Target sections =="
nl -ba "$FILE" | sed -n '90,150p'
echo
nl -ba "$FILE" | sed -n '250,330p'
echo "== Find gh run list calls =="
rg -n 'gh_json\("run", "list"|gh\("run", "list"|workflow", "build\.yml"|build\.yml' "$FILE"Repository: projectbluefin/common
Length of output: 148
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/hive-status-sync.yml"
echo "== Target sections =="
cat -n "$FILE" | sed -n '90,160p'
echo
cat -n "$FILE" | sed -n '250,330p'
echo
echo "== Find gh run list calls =="
rg -n 'gh_json\("run", "list"|gh\("run", "list"|' "$FILE"
rg -n '"workflow", *"build\.yml"' "$FILE"
rg -n '--branch|--event' "$FILE"Repository: projectbluefin/common
Length of output: 21785
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/build.yml"
echo "== build.yml triggers =="
if [ -f "$FILE" ]; then
cat -n "$FILE" | sed -n '1,160p'
else
echo "Missing $FILE"
fiRepository: projectbluefin/common
Length of output: 4085
Scope CI lookup to main (avoid picking the newest PR build).
Both CI lookups in .github/workflows/hive-status-sync.yml list the newest build.yml run repo-wide (no --branch/--event), so a failing PR/feature-branch run can flip the status body and project title even when main is still green.
Proposed fix
- ci_runs = gh_json("run", "list", "--repo", REPO, "--workflow", "build.yml",
- "--limit", "1", "--json", "conclusion,url")
+ ci_runs = gh_json("run", "list", "--repo", REPO, "--workflow", "build.yml",
+ "--branch", "main", "--event", "push",
+ "--limit", "1", "--json", "conclusion,url")- ci_raw = gh("run", "list", "--repo", REPO, "--workflow", "build.yml",
- "--limit", "1", "--json", "conclusion")
+ ci_raw = gh("run", "list", "--repo", REPO, "--workflow", "build.yml",
+ "--branch", "main", "--event", "push",
+ "--limit", "1", "--json", "conclusion")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ci_runs = gh_json("run", "list", "--repo", REPO, "--workflow", "build.yml", | |
| "--limit", "1", "--json", "conclusion,url") | |
| if ci_runs: | |
| run = ci_runs[0] | |
| conclusion = run.get("conclusion", "") | |
| url = run.get("url", "") | |
| if conclusion == "success": | |
| ci_label = f"[✅ build stable]({url})" | |
| elif conclusion in ("failure", "startup_failure"): | |
| ci_label = f"[❌ build degraded]({url})" | |
| else: | |
| ci_label = f"[⏳ build running]({url})" | |
| ci_runs = gh_json("run", "list", "--repo", REPO, "--workflow", "build.yml", | |
| "--branch", "main", "--event", "push", | |
| "--limit", "1", "--json", "conclusion,url") | |
| if ci_runs: | |
| run = ci_runs[0] | |
| conclusion = run.get("conclusion", "") | |
| url = run.get("url", "") | |
| if conclusion == "success": | |
| ci_label = f"[✅ build stable]({url})" | |
| elif conclusion in ("failure", "startup_failure"): | |
| ci_label = f"[❌ build degraded]({url})" | |
| else: | |
| ci_label = f"[⏳ build running]({url})" |
🤖 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/hive-status-sync.yml around lines 114 - 125, The CI lookup
currently grabs the latest workflow run repo-wide and can pick PR or
feature-branch builds; update the gh_json("run", "list", ...) call that
populates ci_runs so it is scoped to the default branch by adding the branch
filter (e.g., --branch main) or equivalent flag, ensuring ci_runs (and the
subsequent run/conclusion/url logic) only considers runs from main rather than
the newest repo-wide run.
| def count_label(label): | ||
| raw = gh_json("issue", "list", "--repo", REPO, | ||
| "--label", label, "--state", "open", "--json", "number") | ||
| return len(raw) if raw else 0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
gh issue list --help | sed -n '/--limit/,+2p'Repository: projectbluefin/common
Length of output: 247
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/hive-status-sync.yml"
echo "== file =="
wc -l "$FILE"
echo "== lines 110-170 =="
nl -ba "$FILE" | sed -n '110,170p'
echo "== lines 270-330 =="
nl -ba "$FILE" | sed -n '270,330p'
echo "== occurrences of issue list + json number =="
rg -n 'gh(_json)?\("issue",\s*"list"' "$FILE" || true
rg -n '--limit' "$FILE" || true
rg -n 'paginate' "$FILE" || trueRepository: projectbluefin/common
Length of output: 200
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/hive-status-sync.yml"
echo "== lines 110-170 =="
sed -n '110,170p' "$FILE" | cat -n
echo "== lines 270-330 =="
sed -n '270,330p' "$FILE" | cat -n
echo "== search for issue list calls =="
rg -n 'gh(_json)?\("issue",\s*"list"' "$FILE" || true
rg -n 'gh(_json)?\("issue",\s*"list"' "$FILE" -n || true
echo "== search for --limit usage =="
rg -n -- '--limit' "$FILE" || true
echo "== search for --paginate usage =="
rg -n -- '--paginate' "$FILE" || true
echo "== search for helper wrapper definitions (gh_json/gh) =="
rg -n 'function\s+gh_json|gh_json\s*\(\)|function\s+gh\b|gh\s*\(\)|REPO=' "$FILE" || trueRepository: projectbluefin/common
Length of output: 6506
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/hive-status-sync.yml"
echo "== search for gh_json implementation =="
rg -n --hidden --no-messages 'gh_json' "$FILE" || true
echo "== search for subprocess.run calls that include gh arguments =="
rg -n --hidden --no-messages 'subprocess\.run\(\["gh"' "$FILE" || true
echo "== show broader context around first gh_json occurrence =="
first=$(rg -n 'gh_json' "$FILE" | head -n 1 | cut -d: -f1)
start=$(( first-40 ))
end=$(( first+40 ))
sed -n "${start},${end}p" "$FILE" | cat -nRepository: projectbluefin/common
Length of output: 4846
🌐 Web query:
gh issue list --paginate --json number output behavior default --limit 30
💡 Result:
The command gh issue list --paginate --json number --limit 30 functions by fetching issues from the specified repository while applying the following behaviors: 1. Limit: The --limit 30 flag sets the total number of issues to fetch [1][2]. Even though 30 is the default limit for gh issue list, explicitly setting it ensures the command retrieves exactly that many results [1][3]. 2. Pagination: The --paginate flag instructs the GitHub CLI to automatically follow pagination links (API responses) to fetch all pages of results until the specified limit is reached [4][5]. While --limit 30 typically requires only one API request, --paginate ensures that if the API's default page size were smaller than the limit (or if you increased the limit beyond a single page's capacity), the CLI would continue requesting subsequent pages until the limit is met [5]. 3. JSON Output: The --json number flag constrains the command's output to a JSON array containing only the number field for each issue [4]. This is useful for scripts or tools (like jq) that require structured data rather than the default text-based display [4]. In summary, this command will output a JSON array of up to 30 issue numbers, automatically handling any necessary pagination to reach that total count [4][5].
Citations:
- 1: https://cli.github.com/manual/gh_issue_list
- 2: https://man.archlinux.org/man/gh-issue-list.1.en
- 3: gh label list is limited to 30 labels cli/cli#8596
- 4: https://ull-ocw-github-education.github.io/pages/gh.html
- 5: gh repo list with pagination cli/cli#7010
🌐 Web query:
gh issue list --limit 1000 without --paginate fetch more than first page
💡 Result:
When you use gh issue list with a specific --limit (such as 1000), the GitHub CLI automatically handles the pagination required to fetch that many results for you [1][2]. There is no --paginate flag for the gh issue list command itself; it is not necessary because the command internally performs the sequence of API requests needed to fulfill the requested limit [1][2]. Key details regarding this behavior include: * Automatic Pagination: When you set a limit (e.g., --limit 1000), the CLI executes as many sequential API requests as necessary to retrieve that number of issues [1][2]. You do not need to manually handle pages or use a separate flag to enable this [2]. * Performance Considerations: Fetching a large number of items will take longer because it requires multiple network requests [1][2]. For example, fetching 1,000 items involves at least 10 API calls, which may result in a noticeable delay [1]. * Limits: While you can set a high limit (e.g., --limit 9999) to retrieve a large set of issues, be aware of underlying API rate limits and the time required to complete the request [2][3]. * Alternative for Custom APIs: The --paginate flag exists specifically for the gh api command [4][5][3], which allows you to make raw API requests and automatically iterate through all pages of results until no more are available [4][1]. This is distinct from gh issue list, which abstracts this process away through the --limit parameter [1][2]. In summary, you should simply use --limit 1000 (or your desired number) with gh issue list, and the CLI will manage the underlying pagination automatically [1][2].
Citations:
- 1: gh repo list with pagination cli/cli#7010
- 2: pager/
$PAGERsupport forgh repo listcli/cli#5101 - 3: Listing all repositories using `api` without manual pagination cli/cli#3257
- 4: https://stackoverflow.com/questions/72509342/receive-more-than-1000-commits
- 5: https://stackoverflow.com/questions/68800885/how-do-i-set-pagination-options-in-the-gh-command
🌐 Web query:
gh issue list --limit maximum value
💡 Result:
The GitHub CLI (gh) command gh issue list does not have a strict "maximum value" for the --limit flag [1]. The flag accepts any positive integer [1]. While there is no enforced software ceiling on the number you can pass, setting an exceptionally high limit does not bypass the limitations of the underlying GitHub API [1][2]. The command performs pagination automatically to fetch the requested number of items, which means that requesting a very large number of issues will result in multiple API calls, potentially slowing down the command or hitting API rate limits [1][2]. There is no "unlimited" or "all" setting for this flag [1]. If you need to retrieve all issues regardless of count, you must specify a number sufficiently high to cover the total, though this practice is generally discouraged in favor of working with paginated results or smaller, targeted batches [1][2].
Citations:
- 1: Update documentation around
--limitflag restriction cli/cli#4888 - 2: gh repo list with pagination cli/cli#7010
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/hive-status-sync.yml"
echo "== usages of count_label results =="
rg -n 'n_ready|n_claimed|n_p0|queue/agent-ready|queue/claimed|P0 🔥|todo\.projectbluefin\.io' "$FILE" || true
echo "== show section where title is built (around todo.projectbluefin.io) =="
line=$(rg -n 'todo\.projectbluefin\.io' "$FILE" | head -n1 | cut -d: -f1 || true)
if [ -n "${line:-}" ]; then
start=$(( line-40 )); end=$(( line+20 ))
sed -n "${start},${end}p" "$FILE" | cat -n
fiRepository: projectbluefin/common
Length of output: 3348
Prevent truncated queue counts when a label has >30 open issues
count_label() uses gh issue list ... --json number and returns len(...). gh issue list defaults to --limit 30, so any label with more than 30 open issues is undercounted, causing the posted status/title to drift.
Proposed fix
- raw = gh_json("issue", "list", "--repo", REPO,
- "--label", label, "--state", "open", "--json", "number")
+ raw = gh_json("issue", "list", "--repo", REPO,
+ "--label", label, "--state", "open", "--limit", "1000", "--json", "number")- raw = gh("issue", "list", "--repo", REPO,
- "--label", label, "--state", "open", "--json", "number")
+ raw = gh("issue", "list", "--repo", REPO,
+ "--label", label, "--state", "open", "--limit", "1000", "--json", "number")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| def count_label(label): | |
| raw = gh_json("issue", "list", "--repo", REPO, | |
| "--label", label, "--state", "open", "--json", "number") | |
| return len(raw) if raw else 0 | |
| def count_label(label): | |
| raw = gh_json("issue", "list", "--repo", REPO, | |
| "--label", label, "--state", "open", "--limit", "1000", "--json", "number") | |
| return len(raw) if raw else 0 |
🤖 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/hive-status-sync.yml around lines 127 - 130, count_label()
undercounts because gh issue list defaults to --limit 30; update the gh_json
call in count_label to include an explicit high limit (e.g. add "--limit",
"1000") so the full set of open issues for the given label is returned before
taking len(raw); change the call in the count_label function that invokes
gh_json("issue", "list", "--repo", REPO, "--label", label, "--state", "open",
"--json", "number") to include the --limit argument to prevent truncation.
hanthor
left a comment
hanthor
left a comment
There was a problem hiding this comment.
Two blockers:
-
This PR adds identical workflow files (bonedigger.yml, hive-status-sync.yml) to PR #393, which is a superset of this one. Merging both will conflict. Please close one — if #393 is the intended version, close this PR.
-
bonedigger.yml uses secrets: inherit with an unpinned @main ref:
uses: projectbluefin/bonedigger/.github/workflows/lifecycle.yml@main
Any push to that repo's main branch runs with access to all secrets here. Pin to a specific commit SHA.
hanthor
left a comment
hanthor
left a comment
There was a problem hiding this comment.
Two blocking issues remain:
bonedigger.ymlstill usesprojectbluefin/bonedigger/.github/workflows/lifecycle.yml@mainwithsecrets: inherit. Please pin that reusable workflow to a specific commit SHA before merging.- Both #391 and #393 add identical
.github/workflows/bonedigger.ymland.github/workflows/hive-status-sync.yml, so one of the PRs needs to drop those files or the second merge will conflict.
2 participants
Summary
Onboards
projectbluefin/commoninto the hive agent workflow so issues can be queued, claimed, and worked by hive agents.What's added
bonedigger.yml— reusable lifecycle bot fromprojectbluefin/bonediggerwithCommon ⚙️branding. Auto-creates all lifecycle labels (queue/agent-ready,queue/claimed,status/approved, etc.) on first run. Supports/claim/unclaim/approveslash commands.hive-status-sync.yml— hourly sync of hive agent formation status to thetodo.projectbluefin.ioproject (PVT_kwDOCCE0ds4BLZBC). Reports common's build CI state and issue queue counts. Gracefully skips ifPROJECT_TOKENis not set.Manual steps needed after merge
PROJECT_TOKENsecret toprojectbluefin/common(same token used in dakota)P0label toprojectbluefin/common(all other labels are auto-created by bonedigger on first issue open)Test plan
hive-status-syncmanually via workflow_dispatch to verify project status posts correctlySummary by CodeRabbit