chore: update ci and publish workflow versions

[gw0]

Summary

• Add concurrency group to ci workflow
• Explicitly list global permissions (public repos are already publicly readable)
• Update reusable workflows in ci workflow (to match chore: update publish workflow version babylon#1986)
• Update reusable workflows in publish workflow (to match chore: update publish workflow version babylon#1986)

[greptile-apps]

Greptile Summary

This PR updates the CI and publish GitHub Actions workflows to align with changes made in babylonlabs-io/babylon#1986. The changes bump all reusable workflow references to v0.18.1 (pinned by commit SHA), add explicit least-privilege permissions: contents: read at the workflow level, add a concurrency group to ci.yml to cancel superseded runs, and introduce trivy_nofail: true to both pipelines.

Key changes:

• Concurrency group added to ci.yml — prevents redundant runs when multiple commits are pushed quickly to the same branch.
• Explicit permissions (contents: read) added at the top level of both workflows — good security hygiene for public repos.
• Reusable workflow version bumps — all references updated from v0.13.4/v0.14.5/v0.16.1 to v0.18.1, pinned by commit SHA (0adff9d36a387ebfc921621f2e6b357230f8c08e).
• trivy_nofail: true — added to both docker_pipeline jobs. This prevents Trivy vulnerability scan failures from blocking the pipeline. While it avoids CI flakiness from unfixable CVEs, it also means Docker images with known vulnerabilities can pass CI and be published without an explicit gate.

Confidence Score: 4/5

• This PR is safe to merge; the changes are straightforward version bumps and security hygiene improvements with one minor concern around trivy_nofail.
• All reusable workflow references are pinned to a specific commit SHA, reducing supply-chain risk. The explicit permissions: contents: read is a positive security addition. The only non-trivial concern is trivy_nofail: true, which silences Trivy scan failures in both CI and publish pipelines — this is a deliberate trade-off but reduces the security gate on published images. The change is clearly motivated by alignment with the babylon repo, so it is likely intentional.
• .github/workflows/publish.yml — trivy_nofail: true means images with Trivy-detected vulnerabilities will still be published.

Important Files Changed

Filename	Overview
.github/workflows/ci.yml	Adds concurrency group to cancel redundant runs, adds explicit permissions: contents: read, bumps reusable workflow refs from v0.13.4 to v0.18.1, and introduces trivy_nofail: true which silences Trivy scan failures.
.github/workflows/publish.yml	Adds explicit permissions: contents: read at workflow level, bumps reusable workflow refs from v0.14.5/v0.16.1 to v0.18.1, and introduces trivy_nofail: true — meaning Docker images with Trivy-detected vulnerabilities will still be published.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    PR[Pull Request / Push / Tag] --> CG{Concurrency Group\nCancel in-progress?}
    CG -->|New commit supersedes| CANCEL[Cancel old run]
    CG -->|First or latest run| LT[lint_test\nreusable_go_lint_test v0.18.1]
    LT --> E2E[e2e_babylon\nubuntu-22.04]
    LT --> DP[docker_pipeline\nreusable_docker_pipeline v0.18.1]
    DP --> TRIVY{Trivy Scan\ntrivy_nofail: true}
    TRIVY -->|Vulnerabilities found| PASS[Pipeline still passes]
    TRIVY -->|Clean| PASS
    DP --> PUB{publish: false\nCI workflow}

    PR2[Push to main/release/*\nor workflow_dispatch] --> LT2[lint_test\nreusable_go_lint_test v0.18.1]
    LT2 --> E2E2[e2e_babylon\nubuntu-22.04]
    LT2 --> DP2[docker_pipeline\nreusable_docker_pipeline v0.18.1]
    DP2 --> TRIVY2{Trivy Scan\ntrivy_nofail: true}
    TRIVY2 -->|Vulnerabilities found| PUB2[Image still published]
    TRIVY2 -->|Clean| PUB2

Loading

_{Reviews (1): Last reviewed commit: "chore: update ci and publish workflow ve..." | Re-trigger Greptile}

[greptile-apps]

trivy_nofail: true silences vulnerability scan failures

Setting trivy_nofail: true in the docker_pipeline job means that Trivy security scan failures will no longer block the CI pipeline. While this avoids false-positive-induced CI flakiness, it also means that Docker images containing known vulnerabilities will pass CI without any gate. Consider whether this is intentional, or if a trivy_nofail: false (the default) with documented exceptions would better preserve security guardrails.

The same concern applies to publish.yml (line 60), where this setting additionally means potentially vulnerable images will be published to the registry without a blocking failure.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 581d4f9c12

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve security-events for the reusable docker pipeline

Setting the workflow-wide token to contents: read caps every job in this workflow, including the docker_pipeline call. GitHub computes job permissions from the workflow/job permissions blocks, and a called workflow can only maintain or reduce them, so reusable_docker_pipeline.yml@0adff9d no longer receives the security-events: write permission it uses for its upload-sarif steps on public repos. In this repository that means the Docker CI job will now fail on PRs as soon as Hadolint/Trivy tries to upload results to the Security tab.

Useful? React with 👍 / 👎.