Conversation
Refactored workflow to extract versions once in a dedicated job and reuse outputs across all dependent jobs, eliminating code duplication and ensuring consistency. Changes: - Added extract-versions job that runs first and outputs agent/os versions - All other jobs now depend on extract-versions and use needs.extract-versions.outputs - Removed duplicate version extraction code from build-and-test, build-push, and create-manifest jobs - Ensures version consistency across all pipeline stages Benefits: - Single source of truth for version numbers - Eliminates risk of version mismatches between jobs - Reduces workflow complexity and maintenance burden - Improves reliability by ensuring all jobs use identical versions
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request primarily focuses on enhancing project documentation. It introduces a detailed guide for GitHub Copilot, providing comprehensive information on the project's architecture, Docker image profiles, coding standards, and operational aspects for self-hosted GitHub Actions runners. Additionally, it refines the main Highlights
Changelog
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates documentation files, including adding a comprehensive copilot-instructions.md guide and updating the README.md. The changes improve the documentation by removing outdated information and clarifying usage examples.
However, the PR title "Fix/manifest creation retry logic" does not seem to match the content of the changes, which are purely documentation-related. Could you please clarify if there are missing code changes or if the title should be updated to reflect the documentation improvements?
I've added a couple of suggestions to the new copilot-instructions.md file to correct some details regarding GitHub Actions versions and token types.
Note: Security Review has been skipped due to the limited scope of the PR.
| - Matrix strategy for profiles and platforms: | ||
| - **PR builds**: `full` profile only, both `linux/amd64` + `linux/arm64` | ||
| - **Push to main**: all profiles, `linux/amd64` only | ||
| - Always use `actions/checkout@v6` as the first step |
There was a problem hiding this comment.
The documentation suggests using actions/checkout@v6, but this version does not exist. The latest major version for actions/checkout is v4. Please update the documentation to reflect a valid version.
| - Always use `actions/checkout@v6` as the first step | |
| - Always use `actions/checkout@v4` as the first step |
| ## Common Pitfalls | ||
|
|
||
| - **TARGETARCH vs runner arch**: GitHub runner archives use `x64` (not `amd64`) — always map with `$([ "${TARGETARCH}" = "amd64" ] && echo "x64" || echo "arm64")` | ||
| - **Runner registration token vs PAT**: `run.sh` expects a short-lived registration token (starts with `ghs-` or `ghp-`), not a PAT |
There was a problem hiding this comment.
The guidance on tokens is confusing. It incorrectly states that run.sh does not accept a PAT, while also listing a PAT prefix (ghp-). This contradicts the run.sh script's help text, which states it accepts both. To improve clarity, please update the text to reflect that both token types are supported and correct the token prefixes mentioned (e.g., ghs_ for registration tokens).
| - **Runner registration token vs PAT**: `run.sh` expects a short-lived registration token (starts with `ghs-` or `ghp-`), not a PAT | |
| - **Runner registration token vs PAT**: The `run.sh` script accepts either a short-lived registration token (starts with `ghs_`) or a Personal Access Token (PAT, which typically starts with `ghp_`). |
The job-level outputs referenced needs.extract-versions.outputs.* (self- referential), which always resolves to empty strings. This caused all downstream jobs to receive an empty AGENT_VERSION build-arg, resulting in a failed Docker build when constructing the runner download URL. Fix outputs to reference steps.versions.outputs.* as intended.
|
Root cause of CI failure found and fixed (commit b378222) The # BEFORE (broken)
outputs:
agent: ${{ needs.extract-versions.outputs.agent }} # references itself → always empty
os: ${{ needs.extract-versions.outputs.os }}
# AFTER (fixed)
outputs:
agent: ${{ steps.versions.outputs.agent }}
os: ${{ steps.versions.outputs.os }}This correctly propagates the version extracted by the |
1 participant
No description provided.