workflows: ensure 5.0 releases are handled - #11631
Conversation
Signed-off-by: Pat <pat@telemetryforge.io>
📝 WalkthroughWalkthroughGitHub Actions staging-release workflow updated to add conditional support for the 5.0 release line alongside existing 4.x steps: image tag gating, release creation, docs PR checkout refs, and version-update PR checkout refs were split per-version and adjusted accordingly. Changes
Sequence Diagram(s)sequenceDiagram
participant Trigger as GitHub Action (workflow_dispatch)
participant Workflow as staging-release.yaml
participant Release as Release Action
participant Docs as docs repo
participant VersionRepo as version-update repo
Trigger->>Workflow: inputs.version
alt startsWith(inputs.version, "5.0")
Workflow->>Release: create 5.0 release (make_latest: true, tag_name...)
Workflow->>Docs: checkout ref=master -> create docs PR
Workflow->>VersionRepo: checkout ref=master -> create version-update PR
Workflow->>Workflow: run image latest-tag gating for 5.0
else
Workflow->>Release: create 4.2 release (make_latest: false, tag_name...)
Workflow->>Docs: checkout ref=4.2 -> create docs PR
Workflow->>VersionRepo: checkout ref=4.2 -> create version-update PR
Workflow->>Workflow: run image tagging gating for prior versions
end
Release-->>Workflow: release created / assets
Docs-->>Workflow: docs PR opened
VersionRepo-->>Workflow: version-update PR opened
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a1915dc2cd
ℹ️ 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".
| # Only update latest tags for 4.0 releases | ||
| if: startsWith(github.event.inputs.version, '4.') | ||
| # Only update latest tags for 5.0 releases | ||
| if: startsWith(github.event.inputs.version, '5.') |
There was a problem hiding this comment.
The staging-release-images-latest-tags job now runs for any 5.x version (startsWith(..., '5.')), but the release job still marks GitHub releases as latest only for 5.0 (startsWith(inputs.version, '5.0')). This mismatch means a 5.1 (or later) run will still overwrite Docker latest tags even though the workflow does not treat that version as the designated latest release path elsewhere, which can publish unintended images under latest.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/staging-release.yaml (1)
1044-1050: Pin the 5.0 docs checkout ref explicitly.This step currently relies on the docs repo default branch. Setting
ref: masterexplicitly makes behavior deterministic and consistent with the 5.0 version-update job.Proposed fix
- name: Release 5.0 and latest if: startsWith(inputs.version, '5.0') uses: actions/checkout@v6 with: repository: fluent/fluent-bit-docs token: ${{ secrets.GH_PA_TOKEN }} + ref: master🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/staging-release.yaml around lines 1044 - 1050, The "Release 5.0 and latest" checkout step currently uses actions/checkout@v6 without a pinned ref; update the step that uses actions/checkout@v6 for repository "fluent/fluent-bit-docs" (step name "Release 5.0 and latest") to include an explicit ref: master under the with: block so the checkout is deterministic and matches the 5.0 version-update job.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/staging-release.yaml:
- Around line 539-540: The conditional is too broad—replace the current if:
startsWith(github.event.inputs.version, '5.') with a check that targets 5.0
releases only (for example use startsWith(github.event.inputs.version, '5.0') or
a regex match that allows 5.0 and its patch versions like 5.0.x) so the job
won't run for 5.1+/5.2+; update the workflow condition where the if is defined
to use the narrower predicate.
- Line 1158: The YAML job currently sets an unquoted branch/tag reference as
ref: 4.2 which YAML will parse as a number; update the ref entry (the ref key in
the workflow job) to use a string by quoting the value (e.g., ref: '4.2' or ref:
"4.2") so the reference is treated as a string and not a floating-point number.
---
Nitpick comments:
In @.github/workflows/staging-release.yaml:
- Around line 1044-1050: The "Release 5.0 and latest" checkout step currently
uses actions/checkout@v6 without a pinned ref; update the step that uses
actions/checkout@v6 for repository "fluent/fluent-bit-docs" (step name "Release
5.0 and latest") to include an explicit ref: master under the with: block so the
checkout is deterministic and matches the 5.0 version-update job.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9c80c088-c633-45d1-b382-56f5627846f7
📒 Files selected for processing (1)
.github/workflows/staging-release.yaml
Signed-off-by: Eduardo Silva <eduardo@chronosphere.io>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/staging-release.yaml:
- Around line 890-899: The release step "Release 4.2 - not latest" using
softprops/action-gh-release@v2 needs to pin the tag target to the 4.2 branch by
adding a target_commitish entry; update the step's with block (the step
identified by name "Release 4.2 - not latest" and uses:
softprops/action-gh-release@v2) to include target_commitish: '4.2' so newly
created tags are based on the 4.2 branch rather than the default branch.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5160f84f-7e8e-4213-8b9a-da9c0cdc1e54
📒 Files selected for processing (1)
.github/workflows/staging-release.yaml
| - name: Release 4.2 - not latest | ||
| uses: softprops/action-gh-release@v2 | ||
| if: startsWith(inputs.version, '4.2') | ||
| with: | ||
| body: "https://fluentbit.io/announcements/v${{ inputs.version }}/" | ||
| draft: false | ||
| generate_release_notes: true | ||
| name: "Fluent Bit ${{ inputs.version }}" | ||
| tag_name: v${{ inputs.version }} | ||
| make_latest: false |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For softprops/action-gh-release@v2/ the GitHub Releases API, what branch or commit is used whentarget_commitishis omitted andtag_name does not already exist?
💡 Result:
If you create a release with tag_name that doesn’t already exist and you omit target_commitish, GitHub will create the tag from the repository’s default branch, i.e. the current HEAD commit of the default branch at the time the API call runs (typically main or master). [1]
softprops/action-gh-release@v2 follows this behavior: when you don’t set the target_commitish input, the action passes target_commitish as undefined to repos.createRelease, effectively leaving it omitted so GitHub falls back to the default branch. [2]
Sources:
[1] GitHub REST API “Create a release” (target_commitish default) https://docs.github.com/en/rest/releases/releases
[2] softprops/action-gh-release implementation (target_commitish = config.input_target_commitish) https://raw.githubusercontent.com/softprops/action-gh-release/master/src/github.ts
Add target_commitish: '4.2' to pin the release target to the 4.2 branch.
When softprops/action-gh-release creates a new tag that doesn't already exist and target_commitish is omitted, it defaults to the repository's default branch instead of the specified branch. For 4.2 releases, this would create the tag from the wrong branch.
Patch
- name: Release 4.2 - not latest
uses: softprops/action-gh-release@v2
if: startsWith(inputs.version, '4.2')
with:
body: "https://fluentbit.io/announcements/v${{ inputs.version }}/"
draft: false
generate_release_notes: true
name: "Fluent Bit ${{ inputs.version }}"
tag_name: v${{ inputs.version }}
+ target_commitish: '4.2'
make_latest: false🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/staging-release.yaml around lines 890 - 899, The release
step "Release 4.2 - not latest" using softprops/action-gh-release@v2 needs to
pin the tag target to the 4.2 branch by adding a target_commitish entry; update
the step's with block (the step identified by name "Release 4.2 - not latest"
and uses: softprops/action-gh-release@v2) to include target_commitish: '4.2' so
newly created tags are based on the 4.2 branch rather than the default branch.
Signed-off-by: Eduardo Silva <eduardo@chronosphere.io>
2 participants
Addresses #11620 by ensuring relevant changes for 5.0 release process are in place.
Enter
[N/A]in the box, if an item is not applicable to your change.Testing
Before we can approve your change; please submit the following in a comment:
If this is a change to packaging of containers or native binaries then please confirm it works for all targets.
ok-package-testlabel to test for all targets (requires maintainer to do).Documentation
Backporting
Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.
Summary by CodeRabbit