feat(workflows): add GitHub Actions workflow for CLI release candidates#1056
feat(workflows): add GitHub Actions workflow for CLI release candidates#1056jakobmoellerdev wants to merge 1 commit into
Conversation
#### What this does - Introduces a new GitHub Actions workflow file, `release-candidate-cli.yml`, to automate the creation of CLI release candidates. - Allows triggering the workflow manually via `workflow_dispatch` with branch and dry run inputs. - Includes automated version computation, changelog generation, artifact building, artifact attestation, GitHub prerelease creation, and OCI image push to GHCR. #### Why this is needed This workflow streamlines the process of creating CLI release candidates by automating critical steps, ensuring reproducibility and reducing manual effort. It also standardizes versioning and artifact publishing for better release management. Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
85a015d to
7298539
Compare
| COMPONENT_PATH: ${{ env.COMPONENT_PATH }} | ||
| with: | ||
| github-token: ${{ secrets.GITHUB_TOKEN }} | ||
| script: | |
There was a problem hiding this comment.
How about using already existing actions like "paulhatch/semantic-version"?
- name: Compute new RC version
id: compute
uses: paulhatch/semantic-version@v5
with:
tag_prefix: "cli/v"
major_pattern: "(MAJOR)"
minor_pattern: "(MINOR)"
version_format: "${major}.${minor}.${patch}-rc.${increment}"
change_path: "cli/**"
enable_prerelease_mode: true
...This code is quite lengthy.
Alternatively, maybe we should host our own actions..
There was a problem hiding this comment.
the action you linked needs a bit more configuration due to https://github.com/PaulHatch/semantic-version/blob/master/guide.md#branch--tag-versioning but I will try. I agree the code is cumbersome
There was a problem hiding this comment.
I tried a lot but ultimately failed. mainly because:
- the action you linked needs to have an initial tag for the branch cutoff. I believe we do not have this.
- the action you linked does not iterate RCs per run, but instead iterates on conventional commit formats or patterns (like you wrote). I dont believe we want that but happy to discuss.
I only got it to more or less get a calculation okay running with avoiding major breaks, minor breaks and while taking into account that incremenet is the number of commits on the branch since the last tag. not sure what to think of this
| core.setOutput("changelog_b64", encoded); | ||
| await core.summary.addRaw(log).write(); | ||
|
|
||
| - name: Set up Docker Buildx |
There was a problem hiding this comment.
To ensure we use the same actions each time we build, we may want to consider extracting "build" steps into a dedicated workflow and including it here and there.
There was a problem hiding this comment.
I think a shared build workflow with 2 steps is probably a bit overkill and using workflow_call has its own caveats. I will experiment nevertheless
There was a problem hiding this comment.
We will follow nearly the same steps for CLI and Controller for main (dev), RCs, and final releases.
There was a problem hiding this comment.
while I agree I want to move step by step. The actions are quite large as is and I simply dont have capacity to get something much more complex out of the door. Im happy to discuss revisiting this of course!
#### What this PR does / why we need it: - Introduced `Containerfile` to build scratch-based multi-arch container images for the CLI. - Added `build/multiarch/image` task to generate OCI-compatible multi-arch container images. - Adjusted `Taskfile.yml` to support multi-arch builds, leveraging Docker Buildx. - Improved task dependencies to ensure dependencies are downloaded before builds. - Modified resource identity names to reflect new multi-arch CLI structure. #### Why: This enables the CLI to be distributed as platform-compatible container images, improving accessibility across diverse environments. The capability aligns with modern multi-arch support best practices. requirement as prep for #1056 Signed-off-by: Jakob Möller <jakob.moeller@sap.com>
| workflow_dispatch: | ||
| inputs: | ||
| branch: | ||
| description: "Branch to cut to, must match regex releases/v0.[0-9]+" |
There was a problem hiding this comment.
I think this workflow will be called only on-demand, which means every other commit will not be tested. How about running "dry run" each time?
| return; | ||
| } | ||
|
|
||
| const branchMatch = branch.match(/^releases\/v(0\.\d+)/); |
There was a problem hiding this comment.
For cleaner code, I would move these two checks (branch name, go.mod) into individual steps. Of course, it is a minor thing.
| bump = "none"; | ||
| pat = 0; | ||
| rc = 1; | ||
| } |
There was a problem hiding this comment.
Perhaps moving this JavaScript code to a file and executing it from that step?
This will simplify testing this code locally.
|
I will rework this action and open up again when i split it. not worth reviewing further for now. Thanks for the feedback @piotrjanik |
…component-model#1058) #### What this PR does / why we need it: - Introduced `Containerfile` to build scratch-based multi-arch container images for the CLI. - Added `build/multiarch/image` task to generate OCI-compatible multi-arch container images. - Adjusted `Taskfile.yml` to support multi-arch builds, leveraging Docker Buildx. - Improved task dependencies to ensure dependencies are downloaded before builds. - Modified resource identity names to reflect new multi-arch CLI structure. #### Why: This enables the CLI to be distributed as platform-compatible container images, improving accessibility across diverse environments. The capability aligns with modern multi-arch support best practices. requirement as prep for open-component-model#1056 Signed-off-by: Jakob Möller <jakob.moeller@sap.com> Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
What this does
release-candidate-cli.yml, to automate the creation of CLI release candidates.workflow_dispatchwith branch and dry run inputs.Why this is needed
This workflow streamlines the process of creating CLI release candidates by automating critical steps, ensuring reproducibility and reducing manual effort. It also standardizes versioning and artifact publishing for better release management.
Which issue(s) this PR fixes
fix open-component-model/ocm-project#699