ci(labels): apply namespaced gittensor reward labels - #401
Merged
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
gittensory-ui | dfd20af | Commit Preview URL Branch Preview URL |
Jun 05 2026, 08:11 PM |
|
Note Gittensory Gate skippedPR closed before full evaluation. No late first comment was created.
Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers. |
ghost
added
the
JSONbored
added a commit
that referenced
this pull request
Jul 20, 2026
…7408) Two independent hygiene fixes from the follow-up audit, bundled since both are small and neither conflicts with the other. Node-version drift: 13 release/publish-adjacent workflows hardcoded node-version: 24.18.0 while .nvmrc pins 22 -- every PR-facing workflow (ci.yml, ui-preview.yml, ui-deploy.yml, ui-sentry-release.yml, mcp-release-candidate.yml) already correctly used node-version-file: .nvmrc. Investigated before touching anything: none of the published packages' own engines fields (@loopover/engine, mcp, ui-kit all >=22.0.0; miner >=22.13.0) require Node 24, no comment anywhere explains the choice, and git history shows each was just whatever version was current when that particular publish workflow was first scaffolded, never reconciled against .nvmrc. Switched all 13 (18 occurrences) to node-version-file: .nvmrc for consistency. Left the two files already pinned to 22.23.1 alone (gittensor-impact.yml, visual-capture-fallback.yml) -- same major version as .nvmrc, not actually inconsistent, lower value/higher risk to touch than the real Node-24-vs-22 mismatch. Composite-action schema validation: this repo's actionlint (both the npm wrapper and the raw upstream binary, tested directly) does not support .github/actions/**/action.yml files at all -- confirmed a genuine, long-standing limitation (rhysd/actionlint#46 and #401, open since 2021), not a configuration gap. Every file passed to actionlint is parsed as a workflow regardless of shape, so it errors on runs/inputs/outputs as unexpected top-level keys rather than actually validating the composite action. scripts/lint-composite-actions.mjs is the closest available substitute: validates against GitHub's own official action-metadata JSON Schema (vendored locally at scripts/schemas/github-action.schema.json, not fetched live, so this check doesn't depend on network access in CI), plus a dedicated check for one thing the schema alone doesn't catch -- every run: step in a composite action needs an explicit shell:, unlike a top-level workflow job which defaults to bash. Verified it actually catches real problems, not just that it exists: fed it a deliberately broken action file (missing shell:, an invalid uses: type) and confirmed both classes of error surface clearly. Wired into test:ci (npm run lint:composite-actions) and a new "Lint composite actions" step in ci.yml, alongside the existing "Lint workflows" step. Also added .github/actions/** to the backend path filter -- it was missing entirely (only .github/workflows/** was covered), so a PR editing ONLY a composite action file would previously trigger neither this new check nor the existing actionlint step at all.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
gittensor:featuregittensor:prioritymanual-only while preventing auto-label churn when it is presentWhat changed
scripts/github-type-label.mjsnow appliesgittensor:bugandgittensor:featureinstead of plainbugandfeature.gittensor:priorityremains manual.Why
The Gittensor registry config now uses explicit
gittensor:*labels with a zero default multiplier. CI should support that policy without turning every normal feature label into a scoring label.Validation
npx vitest run test/unit/github-type-label.test.tsgit diff --checknpm run actionlintnpm run typecheckNotes
gittensor:bug,gittensor:feature, andgittensor:prioritywere created in GitHub so the workflow and manual priority flow are ready.