Revert ubuntu-26.04 in fullsend.yaml and disable Renovate github-runner manager
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 77/100
Research direction
Read .github/workflows/fullsend.yaml and .github/renovate.json5, then compare runner references with .github/workflows/prioritize.yml. Revert the stop-fix runner to ubuntu-24.04 and disable Renovate's github-runner manager. Done when the scaffolded workflow references align and Renovate configuration disables that manager; the issue also asks for dashboard and follow-up verification.
Written by the indexing model from the issue text.
Description
What happened
In PR #300, Mend Renovate (hermes-renovate[bot]) opened a dependency update proposing chore(deps): update dependency ubuntu to v26, modifying .github/workflows/fullsend.yaml.
Renovate's built-in github-runner manager detected runs-on: ubuntu-24.04 in the stop-fix job and updated it to runs-on: ubuntu-26.04. However, Renovate did not detect or update the custom workflow input runner_image: ubuntu-24.04 passed to reusable-dispatch.yml under the dispatch job in the same file, nor the matching runner_image: ubuntu-24.04 input in .github/workflows/prioritize.yml. All native ProtoBot CI workflows (ci-workflow.yaml, renovate.yaml) use runs-on: ubuntu-latest.
Because Renovate classified the 24.04 to 26.04 bump as a major version upgrade, platform automerge was disabled per .github/renovate.json5 (matchUpdateTypes: ["patch", "minor"]). Fullsend review was skipped due to the branch filter on renovate/*, and CodeRabbit skipped review because the author was a bot. Maintainer John Strunk silently approved and merged the PR. The modified stop-fix job was never executed or verified during CI because its execution is gated on /fs-fix-stop issue comments.
What could go better
Scaffolded workflow files like .github/workflows/fullsend.yaml and .github/workflows/prioritize.yml are platform-managed artifacts with explicit headers (# This file is managed by fullsend. Do not edit it directly.). Upstream Fullsend manages runner image versions uniformly across shim templates via the __GH_RUNNER__ placeholder.
Allowing Renovate's github-runner manager to update individual runs-on: keys causes two issues:
- Version skew within scaffolded workflows:
stop-fixwas bumped toubuntu-26.04whiledispatchandprioritize.ymlremain onubuntu-24.04. - Unnecessary human review burden: Because major version upgrades are excluded from automerge, maintainers must manually review and merge standalone runner upgrades that only partially apply to platform shims and are never exercised by the repo's regular CI suite.
Because ProtoBot's native workflows use ubuntu-latest, the github-runner manager only ever touches Fullsend shims. Disabling this manager in .github/renovate.json5 avoids uncoordinated runner updates, leaving runner versioning to Fullsend platform upgrades.
Proposed change
-
In
.github/workflows/fullsend.yaml, revert line 94runs-on: ubuntu-26.04back toruns-on: ubuntu-24.04to restore parity with thedispatchjob (runner_image: ubuntu-24.04) and.github/workflows/prioritize.yml(runner_image: ubuntu-24.04). -
In
.github/renovate.json5, add a configuration rule to disable thegithub-runnermanager:
{
"description": "Disable GitHub runner version updates on scaffolded Fullsend workflows",
"matchManagers": ["github-runner"],
"enabled": false,
},
Alternatively, set "github-runner": { "enabled": false } at the root of .github/renovate.json5.
This ensures runner versions in scaffolded shims stay aligned with upstream platform releases rather than ad-hoc Renovate bumps.
Validation criteria
- Verify
.github/workflows/fullsend.yamland.github/workflows/prioritize.ymlconsistently referenceubuntu-24.04across all jobs and runner inputs. - In the repository Dependency Dashboard (redhat-et/ProtoBot#9), verify that Renovate no longer detects or proposes
ubunturunner updates undergithub-actions. - Over the next 90 days, verify that no automated PRs are opened modifying
runs-on:in.github/workflows/fullsend.yaml.
Generated by retro agent from https://github.com/redhat-et/ProtoBot/pull/300
- Dominant language
- Go
- Stars
- 6
- Forks
- 8
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 82
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from redhat-et/ProtoBot
-
Exclude merge queue branches from push trigger in ci-workflow.yaml to eliminate duplicate CI runsOpenbug infra ready-for-triage triaged
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
redhat-et/ProtoBot#312 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
Fix flakiness in TestGoldenFixture by awaiting SCM MCP server exit before workspace restorePossibly taken @fullsend-ai-coder claimed this today. Openbug ready-for-triage ready-to-code
Difficulty 3/5 1-2 days Newbie friendliness 25/100
redhat-et/ProtoBot#311 · 3 comments · 2 reactions ·
Maintainers usually reply within 1 day
-
Support change-set renumbering and ID collision resolution in ears-manager for concurrent PR branchesPossibly taken @jerry-ng2 claimed this 1 day ago. Opencomponent:ears-manager enhancement feature ready-for-triage triaged
Difficulty 5/5 Over a week Newbie friendliness 35/100
redhat-et/ProtoBot#306 · 2 comments · 1 reaction · 1 assignee ·
Maintainers usually reply within 1 day
-
Enforce change-set base freshness and project.yaml metadata hand-edit checks in review-pr skillPossibly taken @fullsend-ai-coder claimed this 6 days ago. Opencomponent:specification-toolkit documentation ready-for-triage ready-to-code
Difficulty 3/5 1-2 days Newbie friendliness 35/100
redhat-et/ProtoBot#294 · 3 comments · 2 reactions ·
Maintainers usually reply within 1 day
-
Add multi-remote fork topology and non-candidate ref test fixtures to ears-manager self-host suiteOpenblocked component:ears-manager ready-for-triage
Difficulty 4/5 3-5 days Newbie friendliness 53/100
redhat-et/ProtoBot#293 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
All issues in redhat-et/ProtoBot
Similar issues
-
pre-migration
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
client.HTTPFetcher doesn't close non-200 response bodies, so connections leakPossibly taken @grempe claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
transparency-dev/tessera#1245 ·
Maintainers usually reply within 2 days
-
Difficulty 1/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
bug e2e
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
shaiknoorullah/hg-mono#1086 ·
Maintainers usually reply within 1 day
-
native
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
prime-radiant-inc/evener#4839 ·
Maintainers usually reply within 1 day