feat(helm): Add workflow for publishing Helm charts to GitHub Pages. #1891
Conversation
…dd Helm chart-releaser config
… and version flag
WalkthroughAdds a Helm packaging-and-publishing GitHub Actions workflow, removes an explicit full-fetch and a Helm lint step from an existing lint workflow, adds Taskfile Helm packaging tasks, updates docs to install from the published Helm repo, and exposes a Helm version flag to docs via Chart.yaml. Changes
Sequence Diagram(s)sequenceDiagram
actor Dev as Developer
participant GH as GitHub Actions
participant Task as Task Runner
participant Helm as Helm CLI
participant Pages as gh-pages
Dev->>GH: Push to main or v* branch / open PR
GH->>Task: Run lint job (on PRs)
Task->>Helm: Run task lint (helm checks)
Helm-->>Task: Lint results
Task-->>GH: Lint job completes
GH->>Task: Run publish job (non-PR)
Task->>Task: Read tools/.../Chart.yaml → derive version
Task->>Helm: Run helm package -> produce .tgz
Helm-->>Task: Packaged chart artifact
Task->>Pages: Checkout gh-pages, merge/update index.yaml, copy .tgz
Pages-->>GH: Push gh-pages with chart artifacts (unless skipped)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/src/user-docs/guides-k8s-deployment.md (1)
296-302: Update helm template command to use repository chart reference.Line 299 still uses a local path (
.) which is inconsistent with the repository-based approach introduced in this PR. The command should reference the repository chart or clarify if local development is intended.📝 Suggested fix
-helm template clp . -f custom-values.yaml +helm template clp clp/clp -f custom-values.yamlOr if previewing with local values before installation:
helm template clp . -f custom-values.yaml +# Or preview from the repository: +helm template clp clp/clp DOCS_VAR_HELM_VERSION_FLAG -f custom-values.yaml
🤖 Fix all issues with AI agents
In @.github/workflows/clp-package-helm.yaml:
- Around line 98-101: The workflow currently always runs git commit -m
"ci(helm): Publish clp-${{env.CHART_VERSION}} ..." which fails when there are no
staged changes; modify the step to detect staged changes before committing by
running a check (e.g., git diff --cached --quiet or git status --porcelain) and
only run git commit when that check indicates there are changes, otherwise skip
the commit/push steps to avoid a non‑zero exit on "nothing to commit".
- Around line 66-70: The current version extraction (the shell command that sets
the variable version via grep on Chart.yaml and a sed) only handles quoted
versions and is brittle; change the pipeline that assigns version (the command
using grep '^version:' and sed) to a more robust extractor that strips the
leading "version:" prefix and removes optional surrounding quotes (e.g., use a
sed/awk pattern that accepts quoted or unquoted values and returns only the
version token), so CHART_VERSION gets the raw version string regardless of
whether Chart.yaml uses quotes.
In `@docs/conf/conf.py`:
- Around line 125-130: The docstring for _get_helm_version_flag is inaccurate:
it claims dev returns an empty string but the function actually returns
"--devel"; update the docstring to reflect the real behavior (describe that it
returns "--version <version>" for stable releases and "--devel" for development
versions) so the documentation matches the implementation.
- Around line 131-140: The current logic that reads Chart.yaml (variables
chart_yaml_path, chart, version) can raise if the file is missing or contains
invalid YAML; wrap the chart_yaml_path.read_text() and yaml.safe_load(...) in a
try/except that catches IOError, OSError, yaml.YAMLError (or a broad Exception)
and on any error return "--devel" to avoid failing the Sphinx build; also update
the function docstring to state that for dev or on error it returns "--devel"
(not an empty string) so the docs match the implementation.
In `@docs/src/user-docs/guides-k8s-deployment.md`:
- Around line 529-530: Replace the generic placeholder in the helm install
example (the line containing "helm install clp <repo-or-path/to/chart> --dry-run
--debug") with the repository-style chart reference now that the chart is
published; update it to use the "<repo-name>/clp" form (and if necessary add a
preceding note to run "helm repo add <repo-name> <url>" before installation) so
readers install from the chart repo rather than a local path.
| git config user.name "$GITHUB_ACTOR" | ||
| git config user.email "$GITHUB_ACTOR@users.noreply.github.com" | ||
| git add "*.tgz" "index.yaml" | ||
| git commit -m "ci(helm): Publish clp-${{env.CHART_VERSION}} from ${{github.ref_name}} (${{github.sha}})." |
There was a problem hiding this comment.
Handle no-op publishes to avoid failing on “nothing to commit”. A re-run with identical artifacts will exit non‑zero on git commit.
🛠️ Proposed fix
git config user.name "$GITHUB_ACTOR"
git config user.email "$GITHUB_ACTOR@users.noreply.github.com"
git add "*.tgz" "index.yaml"
- git commit -m "ci(helm): Publish clp-${{env.CHART_VERSION}} from ${{github.ref_name}} (${{github.sha}})."
- git push
+ if git diff --cached --quiet; then
+ echo "No Helm repo changes to publish."
+ exit 0
+ fi
+ git commit -m "ci(helm): Publish clp-${{env.CHART_VERSION}} from ${{github.ref_name}} (${{github.sha}})."
+ git push🤖 Prompt for AI Agents
In @.github/workflows/clp-package-helm.yaml around lines 98 - 101, The workflow
currently always runs git commit -m "ci(helm): Publish
clp-${{env.CHART_VERSION}} ..." which fails when there are no staged changes;
modify the step to detect staged changes before committing by running a check
(e.g., git diff --cached --quiet or git status --porcelain) and only run git
commit when that check indicates there are changes, otherwise skip the
commit/push steps to avoid a non‑zero exit on "nothing to commit".
| chart_yaml_path = ( | ||
| Path(__file__).parent.parent.parent / "tools/deployment/package-helm/Chart.yaml" | ||
| ) | ||
| chart = yaml.safe_load(chart_yaml_path.read_text()) | ||
|
|
||
| version = chart.get("version") | ||
| if version is not None and "-dev" not in version: | ||
| return f"--version {version}" | ||
|
|
||
| return "--devel" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check if Chart.yaml exists at the specified path
find . -name "Chart.yaml" -type fRepository: y-scope/clp
Length of output: 166
🏁 Script executed:
# Check the current state of the _get_helm_version_flag function and its context
cat -n docs/conf/conf.py | sed -n '120,150p'Repository: y-scope/clp
Length of output: 1224
🏁 Script executed:
# Look for error handling patterns and how yaml is imported/used
rg "yaml\." docs/conf/conf.py -A 2 -B 2Repository: y-scope/clp
Length of output: 241
🏁 Script executed:
# Find where _get_helm_version_flag is called
rg "_get_helm_version_flag" docs/conf/conf.py -B 2 -A 2Repository: y-scope/clp
Length of output: 399
🏁 Script executed:
# Verify Chart.yaml exists at the expected location
find . -path "*/tools/deployment/package-helm/Chart.yaml" -type f -exec head -5 {} \;Repository: y-scope/clp
Length of output: 211
🏁 Script executed:
# Check for any yaml imports and their usage patterns
rg "import yaml" docs/conf/conf.pyRepository: y-scope/clp
Length of output: 66
Add error handling to prevent doc build failures when Chart.yaml is missing or invalid.
The function is called during Sphinx setup to populate documentation variables. If Chart.yaml is missing, unreadable, or contains invalid YAML, the entire documentation build fails with no fallback. Wrap the file read and YAML parse in a try-except to gracefully return "--devel" on error.
Additionally, the docstring states the function returns an empty string "" for dev versions, but it actually returns "--devel". Update the docstring to match the implementation.
🛠️ Proposed fix
- chart = yaml.safe_load(chart_yaml_path.read_text())
-
- version = chart.get("version")
+ try:
+ chart = yaml.safe_load(chart_yaml_path.read_text()) or {}
+ version = chart.get("version")
+ except (FileNotFoundError, yaml.YAMLError, AttributeError):
+ return "--devel"🤖 Prompt for AI Agents
In `@docs/conf/conf.py` around lines 131 - 140, The current logic that reads
Chart.yaml (variables chart_yaml_path, chart, version) can raise if the file is
missing or contains invalid YAML; wrap the chart_yaml_path.read_text() and
yaml.safe_load(...) in a try/except that catches IOError, OSError,
yaml.YAMLError (or a broad Exception) and on any error return "--devel" to avoid
failing the Sphinx build; also update the function docstring to state that for
dev or on error it returns "--devel" (not an empty string) so the docs match the
implementation.
There was a problem hiding this comment.
The Chart.yaml is not expected to be missing. If we ever move it, it is actually better to let the docs building fail so that developers can be reminded to update the docs.
There was a problem hiding this comment.
@junhaoliao, understood! That's a reasonable approach—letting the build fail serves as an explicit signal when the file structure changes, which is consistent with the fail-fast philosophy I see in the CLP project.
One minor note: the docstring currently states the function returns "" for dev versions, but the implementation actually returns "--devel". You might want to update line 129 to say:
:return: "--version <version>" for stable releases, or "--devel" for dev versions.This is just a documentation accuracy fix and doesn't affect the fail-fast behavior.
✏️ Learnings added
Learnt from: junhaoliao
Repo: y-scope/clp PR: 1891
File: docs/conf/conf.py:131-140
Timestamp: 2026-01-22T01:18:27.853Z
Learning: In the CLP project's documentation build (docs/conf/conf.py), when _get_helm_version_flag() reads Chart.yaml, the team prefers to let the build fail if the file is missing or moved, rather than adding error handling with fallbacks. This fail-fast approach serves as a reminder to developers to update the documentation when file structures change.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: Bill-hbrhbr
Repo: y-scope/clp PR: 1261
File: .github/workflows/clp-core-build.yaml:294-332
Timestamp: 2025-08-25T06:29:59.610Z
Learning: In the CLP project, Bill-hbrhbr prefers a "fail fast" approach for CI workflows - allowing potential command availability issues (like getconf in musllinux) to surface through CI failures rather than preemptively adding fallback logic, as they will fix issues when they occur.
Learnt from: junhaoliao
Repo: y-scope/clp PR: 1152
File: components/clp-package-utils/clp_package_utils/general.py:0-0
Timestamp: 2025-08-19T14:41:28.901Z
Learning: In the CLP codebase, prefer explicit failures over automatic directory creation in utility functions like dump_config. The user junhaoliao prefers to let file operations fail when parent directories don't exist, as this helps catch implementation errors during development rather than masking setup issues with automatic directory creation.
Learnt from: kirkrodrigues
Repo: y-scope/clp PR: 1885
File: docs/src/user-docs/guides-k8s-deployment.md:586-589
Timestamp: 2026-01-19T12:06:21.961Z
Learning: In the y-scope/clp project documentation built with Sphinx, relative paths work for linking to files within the repository, but directory links require GitHub URLs. When linking to directories (e.g., the Helm chart at tools/deployment/package-helm/), use GitHub URLs with DOCS_VAR_CLP_GIT_REF to keep them version-agnostic.
Learnt from: junhaoliao
Repo: y-scope/clp PR: 1466
File: .github/workflows/clp-rust-checks.yaml:14-15
Timestamp: 2025-10-22T21:14:12.225Z
Learning: Repository y-scope/clp: In GitHub Actions workflows (e.g., .github/workflows/clp-rust-checks.yaml), YAML anchors/aliases are acceptable and preferred to avoid duplication; if actionlint flags an alias node (e.g., on push.paths) as an error, treat it as a tool limitation and do not require inlining unless the team asks to silence the warning.
Learnt from: junhaoliao
Repo: y-scope/clp PR: 0
File: :0-0
Timestamp: 2025-10-22T21:02:31.113Z
Learning: Repository y-scope/clp: Maintain deterministic CI/builds for Rust; add a check to verify Cargo.lock is in sync with Cargo.toml without updating dependencies (non-mutating verification in clp-rust-checks workflow).
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/clp-package-helm.yaml:
- Around line 3-14: The pull_request and push trigger blocks both duplicate the
same paths array; replace the duplicated arrays with a YAML anchor/alias: define
an anchor (e.g., &common_paths) for the shared paths list and reference it under
both pull_request.paths and push.paths using the alias (*common_paths) so both
triggers reuse the same paths definition while keeping the existing entries
(".github/workflows/clp-package-helm.yaml", "taskfiles/helm.yaml",
"tools/deployment/package-helm/**").
♻️ Duplicate comments (1)
.github/workflows/clp-package-helm.yaml (1)
66-70: Chart version extraction only handles quoted values.This concern was previously raised. The
sedregex requires quotes around the version value. IfChart.yamlever uses an unquoted version (e.g.,version: 0.1.2), the extraction will fail.
| on: | ||
| pull_request: | ||
| paths: | ||
| - ".github/workflows/clp-package-helm.yaml" | ||
| - "taskfiles/helm.yaml" | ||
| - "tools/deployment/package-helm/**" | ||
| push: | ||
| paths: | ||
| - ".github/workflows/clp-package-helm.yaml" | ||
| - "taskfiles/helm.yaml" | ||
| - "tools/deployment/package-helm/**" | ||
| workflow_dispatch: |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider using YAML anchor for duplicate paths.
The paths array is identical for both pull_request and push triggers. Per repository conventions, YAML anchors are preferred to avoid duplication.
♻️ Suggested refactor
on:
pull_request:
- paths:
+ paths: &helm_paths
- ".github/workflows/clp-package-helm.yaml"
- "taskfiles/helm.yaml"
- "tools/deployment/package-helm/**"
push:
- paths:
- - ".github/workflows/clp-package-helm.yaml"
- - "taskfiles/helm.yaml"
- - "tools/deployment/package-helm/**"
+ paths: *helm_paths
workflow_dispatch:Based on learnings, YAML anchors/aliases are acceptable and preferred in this repository's workflows.
📝 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.
| on: | |
| pull_request: | |
| paths: | |
| - ".github/workflows/clp-package-helm.yaml" | |
| - "taskfiles/helm.yaml" | |
| - "tools/deployment/package-helm/**" | |
| push: | |
| paths: | |
| - ".github/workflows/clp-package-helm.yaml" | |
| - "taskfiles/helm.yaml" | |
| - "tools/deployment/package-helm/**" | |
| workflow_dispatch: | |
| on: | |
| pull_request: | |
| paths: &helm_paths | |
| - ".github/workflows/clp-package-helm.yaml" | |
| - "taskfiles/helm.yaml" | |
| - "tools/deployment/package-helm/**" | |
| push: | |
| paths: *helm_paths | |
| workflow_dispatch: |
🤖 Prompt for AI Agents
In @.github/workflows/clp-package-helm.yaml around lines 3 - 14, The
pull_request and push trigger blocks both duplicate the same paths array;
replace the duplicated arrays with a YAML anchor/alias: define an anchor (e.g.,
&common_paths) for the shared paths list and reference it under both
pull_request.paths and push.paths using the alias (*common_paths) so both
triggers reuse the same paths definition while keeping the existing entries
(".github/workflows/clp-package-helm.yaml", "taskfiles/helm.yaml",
"tools/deployment/package-helm/**").
junhaoliao
requested review from
hoophalab and
kirkrodrigues
and removed request for
kirkrodrigues
| version=$( | ||
| grep '^version:' "tools/deployment/package-helm/Chart.yaml" \ | ||
| | sed 's/version: *"\(.*\)"/\1/' | ||
| ) |
There was a problem hiding this comment.
How about doing this with yq?
There was a problem hiding this comment.
i thought about it but it's not available by default on GH action runners. that said, i did find this action provided by the same maintainer: https://github.com/marketplace/actions/yq-portable-yaml-processor . alternatively, i suppose we can use go install to install it oo.
just wanna make sure whether we are fine with the extra dependency
There was a problem hiding this comment.
Yeah, I'm fine with the extra dependency. It's just in the workflow anyway?
| ```{code-block} yaml | ||
| :caption: dedicated-scheduling.yaml | ||
| distributedDeployment: true |
There was a problem hiding this comment.
Hm, this seems unrelated to the PR?
There was a problem hiding this comment.
right, i was trying to fix an length violation on this line, then i found the unnecessary cmdline override, so i just fixed it. anyways i agree it's a separate issue and should be fixed in another PR.
@coderabbitai so you may see that i moved the distributedDeployment setting from the command-line into the custom-values.yaml for consistency. the improvements are not strictly related to the purpose of this PR though. i'll revert the changes in this PR but please create an issue to track this potential improvement.
There was a problem hiding this comment.
🧩 Analysis chain
@junhaoliao, I'll create an issue to track this improvement.
🏁 Script executed:
#!/bin/bash
# Create a GitHub issue to track the improvement
gh issue create \
--repo y-scope/clp \
--title "docs: Move distributedDeployment setting to YAML examples for consistency" \
--body "## Context
In the Kubernetes deployment guide, some examples use command-line \`--set distributedDeployment=true\` while others could benefit from having this setting in the YAML example files for consistency.
## Improvement
Move the \`distributedDeployment\` setting from command-line overrides into the YAML example files (e.g., \`dedicated-scheduling.yaml\`, \`shared-scheduling.yaml\`) for better consistency and clarity.
## References
- PR: https://github.com/y-scope/clp/pull/1891
- Comment: https://github.com/y-scope/clp/pull/1891#discussion_r2718465254
- Requested by: `@junhaoliao`" \
--assignee junhaoliao
Length of output: 42
@junhaoliao, I've created issue #1900 to track this improvement: #1900
The issue documents the goal of moving distributedDeployment settings from command-line overrides into the YAML example files for better consistency in the Kubernetes deployment guide.
🧠 Learnings used
Learnt from: kirkrodrigues
Repo: y-scope/clp PR: 1885
File: docs/src/user-docs/guides-k8s-deployment.md:586-589
Timestamp: 2026-01-19T12:06:21.961Z
Learning: In the y-scope/clp project documentation built with Sphinx, relative paths work for linking to files within the repository, but directory links require GitHub URLs. When linking to directories (e.g., the Helm chart at tools/deployment/package-helm/), use GitHub URLs with DOCS_VAR_CLP_GIT_REF to keep them version-agnostic.
Learnt from: quinntaylormitchell
Repo: y-scope/clp PR: 968
File: docs/src/user-guide/quick-start/overview.md:73-109
Timestamp: 2025-06-18T20:39:05.899Z
Learning: The CLP project team prefers to use video content to demonstrate detailed procedural steps (like tarball extraction) rather than including every step in the written documentation, keeping the docs focused on conceptual guidance.
Learnt from: junhaoliao
Repo: y-scope/clp PR: 1466
File: .github/workflows/clp-rust-checks.yaml:14-15
Timestamp: 2025-10-22T21:14:12.225Z
Learning: Repository y-scope/clp: In GitHub Actions workflows (e.g., .github/workflows/clp-rust-checks.yaml), YAML anchors/aliases are acceptable and preferred to avoid duplication; if actionlint flags an alias node (e.g., on push.paths) as an error, treat it as a tool limitation and do not require inlining unless the team asks to silence the warning.
Learnt from: junhaoliao
Repo: y-scope/clp PR: 0
File: :0-0
Timestamp: 2025-10-22T21:02:31.113Z
Learning: Repository y-scope/clp: Maintain deterministic CI/builds for Rust; add a check to verify Cargo.lock is in sync with Cargo.toml without updating dependencies (non-mutating verification in clp-rust-checks workflow).
| helm install clp clp/clp DOCS_VAR_HELM_VERSION_FLAG \ | ||
| -f dedicated-scheduling.yaml |
| distributedDeployment: true |
| # Clone the repository (if you haven't already) | ||
| git clone --branch DOCS_VAR_CLP_GIT_REF https://github.com/y-scope/clp.git | ||
| cd clp/tools/deployment/package-helm | ||
| # If you haven't already, add the CLP Helm repository. |
There was a problem hiding this comment.
What happens if you had already added the repo?
There was a problem hiding this comment.
harmless unless the user have added another Helm repo also with name "clp" locally:
> helm repo add clp https://junhaoliao.github.io/clp
"clp" has been added to your repositories
> helm repo add clp https://junhaoliao.github.io/clp
"clp" already exists with the same configuration, skipping
There was a problem hiding this comment.
actually, their prompts are quite intuitive:
# ... following above commands
> helm repo add clp https://y-scope.github.io/clp
Error: repository name (clp) already exists, please specify a different name
There was a problem hiding this comment.
i guess users may blindly run the command then. i can see the docstring may confuse / cause mental barrier for them to the run the command, though i can't think of better wordings. do you have any suggestions?
There was a problem hiding this comment.
Yeah, I feel like we can simply remove the comment?
…view Co-authored-by: kirkrodrigues <2454684+kirkrodrigues@users.noreply.github.com>
… from code review Co-authored-by: kirkrodrigues <2454684+kirkrodrigues@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/src/user-docs/guides-k8s-deployment.md (1)
296-302: Clarify thehelm templatecommand context.The tip uses
helm template clp .which references the current directory (local chart), but the surrounding section demonstrates repository-based installation. This is inconsistent with the debugging section (lines 528-532), which explicitly distinguishes between repository and local chart scenarios.Consider updating to match the repository-based flow or providing both options with clear context:
::::{tip} To preview the generated Kubernetes manifests before installing: **For the published chart:** ```bash helm template clp clp/clp DOCS_VAR_HELM_VERSION_FLAG -f custom-values.yamlFor local chart development:
helm template clp . -f custom-values.yaml::::
</blockquote></details> </blockquote></details>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/clp-package-helm.yaml:
- Around line 18-22: The workflow's global concurrency group uses "${{
github.ref }}" which allows runs from different branches to execute in parallel
and causes gh-pages push races; update the publishing job (the job named
"publish") to use its own concurrency block (or change the global block) so the
group is unique for gh-pages pushes (e.g., a publish-specific group string) and
keep cancel-in-progress: true; modify the concurrency.group value referenced in
the workflow to a fixed publish-only identifier for the publish job instead of
including "${{ github.ref }}" so publish runs are serialized and
non-fast-forward failures are avoided.
| concurrency: | ||
| group: "${{github.workflow}}-${{github.ref}}" | ||
|
|
||
| # Cancel in-progress jobs for efficiency | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/clp-package-helm.yamlRepository: y-scope/clp
Length of output: 4480
🌐 Web query:
GitHub Actions concurrency group github.ref multiple branches parallel execution same job
💡 Result:
In GitHub Actions, only runs that resolve to the exact same concurrency.group value will block/cancel each other. So whether the “same job” can run in parallel across branches depends entirely on what string your group expression produces. (docs.github.com)
What github.ref does for multiple branches
- On
pushevents,github.refis the full branch ref (for examplerefs/heads/main,refs/heads/feature-x). That means different branches produce different group keys, so they can run in parallel when you usegroup: ${{ github.ref }}(or include it in a longer string). (docs.github.com) - On
pull_requestevents,github.refis not the source branch; it’s typically a PR ref likerefs/pull/<n>/merge, so concurrency will be “per PR ref,” not “per branch name.” (docs.github.com)
Recommended patterns
1) Parallel across branches, but serialized per-branch (common)
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: trueThis allows branch A and branch B to run in parallel, but new runs on the same branch cancel/queue each other. (docs.github.com)
2) “Per source branch” behavior for PRs + pushes (avoid PR github.ref mismatch)
concurrency:
group: ${{ github.workflow }}-${{ github.head_ref || github.ref_name }}
cancel-in-progress: truegithub.head_ref exists only for PR events, so the fallback avoids errors and keeps a stable “branch-like” key across event types. (docs.github.com)
If you share your trigger (push, pull_request, etc.) and your current concurrency: block, I can tell you exactly why your runs are (or aren’t) parallelizing.
Citations:
- 1: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency?utm_source=openai
- 2: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency?utm_source=openai
- 3: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions?utm_source=openai
- 4: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency?utm_source=openai
- 5: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions?utm_source=openai
Serialise publishing to avoid gh-pages push races.
The concurrency group includes ${{ github.ref }}, which generates different group values for different branches. This allows the publish job on main and v* release branches to run in parallel. Since both push to the same gh-pages branch, simultaneous pushes create non-fast-forward failures. Add a publish-specific concurrency group to serialise updates.
🛠️ Suggested fix (publish-only concurrency)
publish:
+ concurrency:
+ group: "${{github.workflow}}-gh-pages"
+ cancel-in-progress: true
# Publish from `main` and `vA.B.C` release branches.
if: >-
github.event_name != 'pull_request'
&& (github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/heads/v'))🤖 Prompt for AI Agents
In @.github/workflows/clp-package-helm.yaml around lines 18 - 22, The workflow's
global concurrency group uses "${{ github.ref }}" which allows runs from
different branches to execute in parallel and causes gh-pages push races; update
the publishing job (the job named "publish") to use its own concurrency block
(or change the global block) so the group is unique for gh-pages pushes (e.g., a
publish-specific group string) and keep cancel-in-progress: true; modify the
concurrency.group value referenced in the workflow to a fixed publish-only
identifier for the publish job instead of including "${{ github.ref }}" so
publish runs are serialized and non-fast-forward failures are avoided.
kirkrodrigues
left a comment
kirkrodrigues
left a comment
There was a problem hiding this comment.
New changes look good apart from the comments I posted in replies.
2 participants
Description
This PR adds a GitHub Actions workflow to lint and publish Helm charts to GitHub Pages, removing
the need for users to manually download and extract the chart from the repository.
Changes
Workflow (
clp-package-helm)task lint:check-helmon all PRs and pushes that modify the workflow,taskfile, or Helm chart files.
gh-pagesbranch. Only runs onpushes to
mainandv*release branches (not on PRs).The workflow:
Chart.yamlhelm package.tgzfile to thegh-pagesbranchindex.yamlusinghelm repo index --mergegh-pagesTaskfile (
taskfiles/helm.yaml)Adds a new taskfile with a
helm:packagetask that:build/clp-package-helm/Documentation updates
Updates the Kubernetes deployment docs to use the Helm repository instead of cloning/downloading
the chart:
The
DOCS_VAR_HELM_VERSION_FLAGplaceholder is replaced at docs build time:v0.8.0):--version 0.1.2main):--develChecklist
breaking change.
Validation performed
1. Workflow execution on
mainbranchPushed to
junhao/mainand verified the workflow completed successfully:Verified the commit message on
gh-pages:2. Workflow execution on
v0.8.0release branchCreated
junhao/v0.8.0with the workflow changes (rebased on top of version bump commit) andverified publication of stable release:
Verified the commit message on
gh-pages:3. Helm repository functionality
Add repository
$ helm repo add junhao-clp https://junhaoliao.github.io/clp "junhao-clp" has been added to your repositoriesUpdate repository
Search for available versions
Pull stable version from v0.8.0 release branch
Pull dev version from main branch
Template chart (dry-run)
4. Published index.yaml
Verified the
gh-pagesbranch contains both dev and stable versions:The Helm repository now contains:
v*branches (e.g.,0.1.2withappVersion: 0.8.0)mainbranch (e.g.,0.1.2-dev.19withappVersion: 0.7.1-dev)Summary by CodeRabbit
New Features
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.