Repository navigation
ci: move Linux CI to self-hosted ARC (sized -4/-8) - #47
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Summary by CodeRabbit
WalkthroughThis PR updates GitHub Actions workflows to use configurable runner selection with ChangesCI Workflow Runner and Publish Update
Estimated code review effort: 3 (Moderate) | ~20 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 |
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
Greptile SummaryThis PR moves Linux CI jobs onto the sized self-hosted ARC runner labels. The main changes are:
Confidence Score: 4/5The Docker publish workflows need a Docker-capable ARC runner before merging.
.github/workflows/docker-build-publish-dev.yml, .github/workflows/docker-build-publish-stage.yml, .github/workflows/docker-build-publish-prod.yml Important Files Changed
Reviews (1): Last reviewed commit: "ci: move Linux CI to sized self-hosted A..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| jobs: | ||
| ever-api-starter-kit-api: | ||
| runs-on: ubuntu-22.04 | ||
| runs-on: ever-k8s-linux-x64-4 |
There was a problem hiding this comment.
When this job runs on an ARC Kubernetes runner, the later docker image, docker rmi, docker push, and Buildx steps need a Docker daemon that GitHub-hosted ubuntu-22.04 provided by default. If ever-k8s-linux-x64-4 is not configured with DinD, privileged access, or a mounted Docker socket, the dev image publish workflow fails before pushing a new image.
| jobs: | ||
| ever-api-starter-kit-api: | ||
| runs-on: ubuntu-22.04 | ||
| runs-on: ever-k8s-linux-x64-4 |
There was a problem hiding this comment.
When this job runs on an ARC Kubernetes runner, the later docker image, docker rmi, docker push, and Buildx steps need a Docker daemon that GitHub-hosted ubuntu-22.04 provided by default. If ever-k8s-linux-x64-4 is not configured with DinD, privileged access, or a mounted Docker socket, the stage image publish workflow fails before pushing a new image.
| jobs: | ||
| ever-api-starter-kit-api: | ||
| runs-on: ubuntu-22.04 | ||
| runs-on: ever-k8s-linux-x64-4 |
There was a problem hiding this comment.
When this job runs on an ARC Kubernetes runner, the later docker image, docker rmi, docker push, and Buildx steps need a Docker daemon that GitHub-hosted ubuntu-22.04 provided by default. If ever-k8s-linux-x64-4 is not configured with DinD, privileged access, or a mounted Docker socket, the prod image publish workflow fails before pushing a new image.
Apply both transforms to all Linux workflow files:
TRANSFORM 1 - Portable runs-on:
- Replace hard-coded ARC labels (ever-k8s-linux-x64-4/8) with org-variable
expressions that fall back to GitHub-hosted
- Change 'runs-on: ever-k8s-linux-x64-4' to
'runs-on: ${{ vars.RUNNER_LINUX_X64_4 || "ubuntu-latest" }}'
- Apply to both scalar runs-on and matrix os entries
- 10 entries converted across 9 workflow files
TRANSFORM 2 - Guard hosted-only steps:
- Add 'if: runner.environment == "github-hosted"' to Free disk space steps
- Ensures GitHub-hosted disk space hacks are skipped on self-hosted runners
- 3 docker-build-publish workflow files guarded
Files modified:
- deploy-do-dev.yml, deploy-do-prod.yml, deploy-do-stage.yml
- docker-build-publish-dev.yml, docker-build-publish-prod.yml, docker-build-publish-stage.yml
- release-dev.yml, release-prod.yml, release-stage.yml
- typos.yml
Verification:
- No bare ever-k8s-linux-x64-* labels remain
- All Free disk space steps have runner.environment guard
- CodeQL, Snyk, and Windows/macOS workflows untouched
Co-Authored-By: Claude Code <noreply@anthropic.com>
|
|
1 similar 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: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/deploy-do-dev.yml (1)
12-98: 🚀 Performance & Scalability | 🔵 TrivialMissing
permissionsblock (pre-existing, flagged by CodeQL).Not introduced by this change, but since this workflow is being touched, consider adding an explicit
permissions:block to limit the defaultGITHUB_TOKENscope.🤖 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/deploy-do-dev.yml around lines 12 - 98, The workflow in the deployment job currently relies on the default GITHUB_TOKEN scope, which CodeQL flags. Add an explicit permissions block at the workflow or job level in deploy-do-dev.yml, keeping only the access needed by the actions in this job, and place it alongside the existing runs-on/environment/steps configuration so it is easy to find and maintain.Source: Linters/SAST tools
🤖 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/deploy-do-prod.yml:
- Around line 12-14: The job in the deploy workflow is reading
vars.RUNNER_LINUX_X64_4 from an environment-scoped var while also setting
environment: prod, so the runner selection in runs-on is resolved before that
var is available. Move the runner selector to a repo/org-scoped variable or
otherwise replace the reference used by runs-on in this workflow job, keeping
the existing deploy job definition and environment: prod intact.
In @.github/workflows/deploy-do-stage.yml:
- Around line 12-14: The deploy-do-stage job is using a stage-scoped variable in
runs-on before the environment is applied, so it may incorrectly fall back to
ubuntu-latest. Update the workflow job to use a runner value that is available
at evaluation time by either moving RUNNER_LINUX_X64_4 to repo/org scope or
replacing the expression with a fixed runner label. Check the job definition
containing runs-on and environment: stage, and keep the runner selection
resolvable without relying on environment-scoped vars.
In @.github/workflows/docker-build-publish-dev.yml:
- Around line 11-12: The Checkout step is using an outdated actions version
flagged by actionlint. Update the existing actions/checkout reference in the
workflow to the newer major version, and keep the change localized to the
Checkout job step so the workflow uses the current supported release.
In @.github/workflows/docker-build-publish-prod.yml:
- Line 12: The workflow uses an outdated, unpinned checkout action and is
missing basic hardening settings. Update the `actions/checkout` reference in the
docker build/publish workflow to a pinned immutable revision, set
`persist-credentials: false`, and add an explicit top-level `permissions` block
for the workflow. Use the workflow file and the `actions/checkout` step as the
fix point.
---
Outside diff comments:
In @.github/workflows/deploy-do-dev.yml:
- Around line 12-98: The workflow in the deployment job currently relies on the
default GITHUB_TOKEN scope, which CodeQL flags. Add an explicit permissions
block at the workflow or job level in deploy-do-dev.yml, keeping only the access
needed by the actions in this job, and place it alongside the existing
runs-on/environment/steps configuration so it is easy to find and maintain.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 23370148-d57b-426b-8c72-eb5c9fb44587
📒 Files selected for processing (11)
.github/actionlint.yaml.github/workflows/deploy-do-dev.yml.github/workflows/deploy-do-prod.yml.github/workflows/deploy-do-stage.yml.github/workflows/docker-build-publish-dev.yml.github/workflows/docker-build-publish-prod.yml.github/workflows/docker-build-publish-stage.yml.github/workflows/release-dev.yml.github/workflows/release-prod.yml.github/workflows/release-stage.yml.github/workflows/typos.yml
| runs-on: ${{ vars.RUNNER_LINUX_X64_4 || 'ubuntu-latest' }} | ||
|
|
||
| environment: prod |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
git ls-files '.github/workflows/*' | sort
printf '\n--- deploy-do-prod.yml ---\n'
cat -n .github/workflows/deploy-do-prod.yml
printf '\n--- deploy-do-dev.yml ---\n'
cat -n .github/workflows/deploy-do-dev.ymlRepository: ever-co/ever-api-starter-kit
Length of output: 13176
🌐 Web query:
GitHub Actions environment-scoped variables resolution order runs-on environment job-level vars docs
💡 Result:
In GitHub Actions, the resolution order and availability of variables depend on whether you are using configuration variables (accessed via the vars context) or environment variables (accessed via the env context or shell environment variables) [1]. These two systems are separate and do not override each other [2][1]. Configuration Variable Precedence Configuration variables (set in the GitHub UI) follow a hierarchical precedence where the lowest-level variable overrides higher-level ones [2][1]. If a variable with the same name is defined at multiple levels, the order of precedence is as follows: 1. Environment-level variables (highest precedence) [2][1] 2. Repository-level variables [2][1] 3. Organization-level variables (lowest precedence) [2] Environment-level variables are only available to jobs that explicitly reference the environment using the environment keyword [3][1]. Note that environment-level variables are not injected into the env context and do not overwrite variables defined in the env block of your workflow [2]. Environment Variable Precedence (env context) Environment variables defined within your workflow file (using the env key) follow a "most specific" rule [4]. When multiple environment variables share the same name, the variable defined at the lowest level takes precedence while that specific component executes [4]: 1. Step-level env (overrides job and workflow levels) [4] 2. Job-level env (overrides workflow level) [4] 3. Workflow-level env [4][5] Key Distinctions - Contexts: Configuration variables are accessed using ${{ vars.NAME }} [1], while workflow-defined environment variables are accessed using ${{ env.NAME }} or standard shell syntax (e.g., $NAME on Linux) [5][1]. - Availability: Environment-level configuration variables (vars) are resolved by GitHub Actions and are available throughout the job if the job references that environment [3]. Workflow-defined env variables are defined in the YAML and injected into the runner's environment [4][5]. - Default Variables: You cannot override default GitHub environment variables [2]. If you attempt to assign a value to a default variable name, the assignment is ignored [2].
Citations:
- 1: https://env.dev/guides/github-actions-secrets-env
- 2: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/variables.md
- 3: https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
- 4: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 5: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables
🌐 Web query:
site:docs.github.com GitHub Actions environment-level configuration variables runs-on evaluated before environment job starts
💡 Result:
No, environment-level configuration variables are not evaluated before the runs-on job configuration is processed [1]. GitHub Actions processes environment-level configuration variables (vars context) and secrets (secrets context) only when a job that references that environment begins execution [1][2]. Because these values are read at the time the job starts—after the workflow has been queued and a runner has been selected—they are not available during the initial evaluation of the job's runs-on property [1]. Consequently, you cannot use environment-level variables or secrets to dynamically determine the runs-on target [1]. If you need to dynamically define the runner, you must use repository-level or organization-level variables, which are available when the workflow run is queued [1][2].
Citations:
- 1: https://docs.github.com/enterprise-server%403.20/actions/reference/workflows-and-actions/variables
- 2: https://docs.github.com/en/actions/reference/security/secrets
Move the runner selector out of environment-scoped vars
environment: prod doesn’t make vars.RUNNER_LINUX_X64_4 available in time for runs-on; environment-level vars are resolved too late, so this job will fall back to ubuntu-latest unless the runner name lives at repo/org scope.
🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 12-97: Workflow does not contain permissions
Actions job or workflow does not limit the permissions of the GITHUB_TOKEN. Consider setting an explicit permissions block, using the following as a minimal starting point: {{contents: read}}
🤖 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/deploy-do-prod.yml around lines 12 - 14, The job in the
deploy workflow is reading vars.RUNNER_LINUX_X64_4 from an environment-scoped
var while also setting environment: prod, so the runner selection in runs-on is
resolved before that var is available. Move the runner selector to a
repo/org-scoped variable or otherwise replace the reference used by runs-on in
this workflow job, keeping the existing deploy job definition and environment:
prod intact.
| runs-on: ${{ vars.RUNNER_LINUX_X64_4 || 'ubuntu-latest' }} | ||
|
|
||
| environment: stage |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== deploy-do-stage.yml ==\n'
sed -n '1,80p' .github/workflows/deploy-do-stage.yml
printf '\n== deploy-do-dev.yml ==\n'
sed -n '1,80p' .github/workflows/deploy-do-dev.yml
printf '\n== search for RUNNER_LINUX_X64_4 and environment usage ==\n'
rg -n "RUNNER_LINUX_X64_4|environment:" .github/workflows -S
printf '\n== GitHub Actions docs references in repo ==\n'
rg -n "vars|environment-scoped|runs-on" README.md .github -SRepository: ever-co/ever-api-starter-kit
Length of output: 11814
🌐 Web query:
GitHub Actions environment-scoped variables runs-on job-level expression evaluation environment order vars context
💡 Result:
In GitHub Actions, the evaluation and availability of environment variables and contexts depend on whether the part of the workflow is processed by the GitHub Actions service (server-side) or by the runner (runner-side) [1]. Key Principles of Evaluation and Order: 1. Server vs. Runner Execution: Parts of a workflow processed by the GitHub Actions service, such as 'if' conditionals used to determine if a job or step should run, cannot access runner-side environment variables or the 'env' context [1]. These sections must use contexts available at the server level, such as 'github', 'vars', or 'secrets' [1][2]. The 'env' context is populated and available only on the runner [3]. 2. Precedence and Overriding: When environment variables with the same name are defined at different levels (workflow, job, step), the most specific variable takes precedence [4]. A step-level variable overrides a job-level variable, which in turn overrides a workflow-level variable during the execution of that specific step [4]. 3. Non-Referential Definition: Variables defined in 'env' maps cannot be defined in terms of other variables within the same map [4]. This prevents circular dependencies or complex sequential resolution within a single 'env' block [4]. 4. Environment-Scoped Variables: Variables associated with a specific environment (defined at the repository/organization level) are only available on the runner after a job starts executing [2]. Consequently, these environment-level variables do not overwrite variables in the 'env' or 'vars' contexts during the server-side evaluation phase [2]. 5. 'runs-on' Evaluation: The 'runs-on' field is evaluated by the GitHub Actions service to determine which runner to dispatch the job to [4]. Because this happens server-side, you cannot reference job-level 'env' variables or runner-specific environment variables within 'runs-on' [1]. You can, however, use variables containing strings or arrays of strings (often from the 'vars' or 'github' context) to dynamically select runners [4]. In summary, server-side evaluations (like 'runs-on' or 'if' conditions) require server-accessible contexts, while the 'env' context is restricted to the runner environment and populated as the job progresses [1][3][2].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables
- 2: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/variables.md
- 3: https://github.com/actions/runner/blob/main/docs/adrs/0278-env-context.md
- 4: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
runs-on cannot read stage-scoped vars
environment: stage is resolved too late for ${{ vars.RUNNER_LINUX_X64_4 }}. If that variable lives only at the stage environment level, this job will fall back to ubuntu-latest instead of the intended runner. Move it to repo/org scope or hardcode the runner here.
🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 12-97: Workflow does not contain permissions
Actions job or workflow does not limit the permissions of the GITHUB_TOKEN. Consider setting an explicit permissions block, using the following as a minimal starting point: {{contents: read}}
🤖 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/deploy-do-stage.yml around lines 12 - 14, The
deploy-do-stage job is using a stage-scoped variable in runs-on before the
environment is applied, so it may incorrectly fall back to ubuntu-latest. Update
the workflow job to use a runner value that is available at evaluation time by
either moving RUNNER_LINUX_X64_4 to repo/org scope or replacing the expression
with a fixed runner label. Check the job definition containing runs-on and
environment: stage, and keep the runner selection resolvable without relying on
environment-scoped vars.
| - name: Checkout | ||
| uses: actions/checkout@v3 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win
Outdated actions/checkout@v3 flagged by actionlint.
Static analysis flags this action version as too old. Since this line sits in the touched hunk, consider bumping to v4 while you're here.
Suggested bump
- - name: Checkout
- uses: actions/checkout@v3
+ - name: Checkout
+ uses: actions/checkout@v4📝 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.
| - name: Checkout | |
| uses: actions/checkout@v3 | |
| - name: Checkout | |
| uses: actions/checkout@v4 |
🧰 Tools
🪛 actionlint (1.7.12)
[error] 12-12: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🪛 zizmor (1.26.1)
[warning] 11-12: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 12-12: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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/docker-build-publish-dev.yml around lines 11 - 12, The
Checkout step is using an outdated actions version flagged by actionlint. Update
the existing actions/checkout reference in the workflow to the newer major
version, and keep the change localized to the Checkout job step so the workflow
uses the current supported release.
Source: Linters/SAST tools
| runs-on: ${{ vars.RUNNER_LINUX_X64_4 || 'ubuntu-latest' }} | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v3 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win
Pre-existing hygiene gaps flagged by static analysis.
actionlint/zizmor/CodeQL surface: actions/checkout@v3 is outdated, unpinned action refs (not pinned to hash), missing persist-credentials: false, and no explicit permissions block on the workflow. These predate this PR's runner-selection change but are worth addressing while the file is being touched.
🔒 Suggested hardening
+permissions:
+ contents: read
+
jobs:
ever-api-starter-kit-api:
runs-on: ${{ vars.RUNNER_LINUX_X64_4 || 'ubuntu-latest' }}
steps:
- name: Checkout
- uses: actions/checkout@v3
+ uses: actions/checkout@v4
+ with:
+ persist-credentials: false🧰 Tools
🪛 actionlint (1.7.12)
[error] 12-12: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🪛 zizmor (1.26.1)
[warning] 11-12: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 12-12: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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/docker-build-publish-prod.yml at line 12, The workflow
uses an outdated, unpinned checkout action and is missing basic hardening
settings. Update the `actions/checkout` reference in the docker build/publish
workflow to a pinned immutable revision, set `persist-credentials: false`, and
add an explicit top-level `permissions` block for the workflow. Use the workflow
file and the `actions/checkout` step as the fix point.
Source: Linters/SAST tools
…eploy off) [skip ci]
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/docker-build-publish-dev.yml (1)
14-15: 🩺 Stability & Availability | 🔵 TrivialVerify ARC runner pod ephemerality to confirm disk-space skip is safe.
The "Free disk space" step now only runs on
github-hostedrunners. On self-hosted ARC runners, Docker images loaded viaload: trueand build caches will not be cleaned up between jobs. If ARC pods are ephemeral (recreated per job), this is fine. If pods persist or use persistent volumes, disk could fill up over time. Verify the ARC configuration onever-k8sto confirm runners are ephemeral.This applies to all three docker-build-publish workflows (dev, prod, stage).
🤖 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/docker-build-publish-dev.yml around lines 14 - 15, Verify the ARC runner pod lifecycle in the docker-build-publish workflows before relying on the `Free disk space` guard in the workflow jobs. Check the `runner.environment == 'github-hosted'` condition and confirm the `ever-k8s` ARC setup is truly ephemeral per job; if pods or volumes persist, keep or replace the cleanup step so `load: true` images and build caches do not accumulate across runs. Apply the same confirmation to the corresponding `Free disk space` step in the dev, prod, and stage workflow files.
🤖 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/deploy-do-dev.yml:
- Around line 12-13: The deploy job is reading vars.RUNNER_LINUX_X64_4 and
vars.DO_ENABLED in job-level keys before environment: dev is applied, so those
values won’t be available if they live only in the environment. Move these
variables to repo/org scope or stop referencing them in runs-on and the
job-level if for the deploy job, and apply the same fix in the stage/prod deploy
workflows where the same pattern appears.
---
Outside diff comments:
In @.github/workflows/docker-build-publish-dev.yml:
- Around line 14-15: Verify the ARC runner pod lifecycle in the
docker-build-publish workflows before relying on the `Free disk space` guard in
the workflow jobs. Check the `runner.environment == 'github-hosted'` condition
and confirm the `ever-k8s` ARC setup is truly ephemeral per job; if pods or
volumes persist, keep or replace the cleanup step so `load: true` images and
build caches do not accumulate across runs. Apply the same confirmation to the
corresponding `Free disk space` step in the dev, prod, and stage workflow files.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: de321433-1cb9-4cd8-9d3d-63afe0af309c
📒 Files selected for processing (6)
.github/workflows/deploy-do-dev.yml.github/workflows/deploy-do-prod.yml.github/workflows/deploy-do-stage.yml.github/workflows/docker-build-publish-dev.yml.github/workflows/docker-build-publish-prod.yml.github/workflows/docker-build-publish-stage.yml
| runs-on: ${{ vars.RUNNER_LINUX_X64_4 || 'ubuntu-latest' }} | ||
| if: ${{ vars.DO_ENABLED == 'true' }} |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for any documentation or configuration that indicates where these vars are defined
rg -n "RUNNER_LINUX_X64_4|DO_ENABLED" .github/ README.md --type yaml -C2Repository: ever-co/ever-api-starter-kit
Length of output: 7927
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Repo-wide references to RUNNER_LINUX_X64_4 / DO_ENABLED:\n'
rg -n --hidden --glob '!.git' 'RUNNER_LINUX_X64_4|DO_ENABLED' .
printf '\nGitHub workflows mentioning environment:\n'
rg -n --hidden --glob '.github/workflows/*.yml' '^\s*environment:' .github/workflowsRepository: ever-co/ever-api-starter-kit
Length of output: 2786
🌐 Web query:
GitHub Actions variables job-level if runs-on environment scope evaluation order environment variables docs
💡 Result:
In GitHub Actions, the evaluation of variables and environment settings follows specific rules based on when and where they are processed. Processing Scope GitHub Actions evaluates workflow components either on the GitHub Actions platform (before the job is sent to a runner) or on the runner itself (after the job has been assigned and started) [1]. 1. GitHub Actions Platform (Pre-Runner): Components such as the if conditional, runs-on target, and variable definitions (using env or vars) are processed by the platform [1]. Because these are processed before the job reaches the runner, you must use context expressions (e.g., ${{ env.VAR }} or ${{ vars.VAR }}) to access values in these fields [1]. You cannot use standard runner environment variables (e.g., $VAR) in these locations because they do not exist on the platform [1]. 2. Runner (Execution): Once a job starts, the runner receives the environment blocks (workflow-level, job-level, and environment-level). These are interpolated and made available as standard system environment variables within the shell [1][2]. Precedence When variables are defined with the same name at different levels, the most specific level takes precedence [3][4]: - Step-level variables override job-level variables [3]. - Job-level variables override workflow-level variables [3]. - Environment-level variables (from the GitHub environment feature) are applied after the job begins executing [4]. Note that environment-level variables do not override variables in the env or vars contexts because they are injected later in the process [4]. Evaluation Constraints Variables defined in the env map cannot be defined in terms of other variables within the same map [3]. Furthermore, you generally cannot compute a job-level environment variable based directly on a workflow-level environment variable within the YAML definition itself, as these blocks are effectively distinct during the parsing phase [2]. Summary of Evaluation Order - Platform Processing: GitHub evaluates runs-on and if conditionals using context expressions before assigning the job to a runner [1]. - Injection: The runner receives the environment configurations, and variables are merged based on precedence (Step > Job > Workflow) [3]. - Execution: Runner environment variables are interpolated during the step execution [1].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables
- 2: Job env variables cant be computed based on Workflow env variables actions/runner#2565
- 3: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 4: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/variables.md
Move these vars out of environment scope or stop using them in job-level keys
runs-on and the job-level if are resolved before environment: dev is applied, so vars.RUNNER_LINUX_X64_4 and vars.DO_ENABLED must be available at repo/org scope here. If they only exist on the dev environment, the job can fall back to ubuntu-latest or skip entirely. The same pattern exists in the stage/prod deploy workflows.
🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 12-99: Workflow does not contain permissions
Actions job or workflow does not limit the permissions of the GITHUB_TOKEN. Consider setting an explicit permissions block, using the following as a minimal starting point: {{contents: read}}
🤖 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/deploy-do-dev.yml around lines 12 - 13, The deploy job is
reading vars.RUNNER_LINUX_X64_4 and vars.DO_ENABLED in job-level keys before
environment: dev is applied, so those values won’t be available if they live
only in the environment. Move these variables to repo/org scope or stop
referencing them in runs-on and the job-level if for the deploy job, and apply
the same fix in the stage/prod deploy workflows where the same pattern appears.
Move Linux CI to sized self-hosted ARC runners
Moves this repo's cloud Linux CI onto our self-hosted ARC pool on
ever-k8s, using sized labels so each job lands on a right-sized runner.Runner sizing
ever-k8s-linux-x64-4deploy-do-{dev,prod,stage}.yml,docker-build-publish-{dev,prod,stage}.yml,release-{dev,prod,stage}.yml(matrixos:),typos.ymlever-k8s-linux-x64-8ubicloud-standard-8/*-8-coresjobs exist in this repo)All previously ran on
ubuntu-22.04orubuntu-latest, which map to the 4-core class per our standard mapping.Left on GitHub-hosted (unchanged, by policy)
codeql-analysis.ymlusesgithub/codeql-action; stays onubuntu-latest.snyk-analysis.yml'sanalyzejob usesgithub/codeql-action/upload-sarif; stays onubuntu-latest.*-arm) / 16-core runners — none present in this repo, none touched.actionlint
Adds
.github/actionlint.yamldeclaring both self-hosted labels (ever-k8s-linux-x64-4,ever-k8s-linux-x64-8) underself-hosted-runner.labels, so lint does not flag the new labels as unknown.Notes
develop; the diff is exactly the runner-label changes plus the actionlint config.