-
Notifications
You must be signed in to change notification settings - Fork 526
migrate CICD-Pipeline to GitHub-Actions #12592
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
4df8de2
to
2ea1476
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
/assign @oliver-goetz |
/cc @tobschli |
@LucaBernstein : in the end, that's of course up to you. The underlying workflows have already been used for some releases in the past (e.g. for dashboard, and also some extensions). I do not think waiting for one more release will make a lot of a difference; if you like, I could drop the deletion of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the PR, just one more question from my side @ccwienk 😃
mode: release | ||
|
||
release-to-github-and-bump: | ||
uses: gardener/cc-utils/.github/workflows/release.yaml@master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you cut releases in cc-utils
or should we pin the references to some tag/hash to ensure reproducability and controlled updates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently (as there is still some ongoing development), there is not yet a branching-model in place. For the time being, it might be considered to pin to commit-digests after release (such as to fixate release-branches), and remain on master
for gardener/gardener's master
-branch.
I will (have to) think of a proper release process, also considering usage for gh-tools/wdf; however, this is out-of scope for initial migration. Also, this is equivalent to concourse-pipelines, where - while there is a QA-step involved - there is also only ever one global pipeline-template-version 🫣
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I think of it, we could even include the commit-pinning into the release.yaml
-workflow so that this will be done automatically upon release, as part of the release-commit. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's some ideas there, thanks for thinking about it.
Maybe later we will introduce versioning in the cc-utils
once it's considered stable(r).
We could go with the as-is for now imho. Maybe, as you suggested, we could eventually pin the utils commit upon release.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
/unhold (done) |
however: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for moving the repo to github actions 🚀
14cec34
to
a948e77
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
LGTM label has been added. Git tree hash: 11e03491c1bf5252fe1755c02df186ee82a9c806
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, let's go 🤞
😄
/approve
/unhold
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: oliver-goetz The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
I had to merge the PR manually, because it is updating Github workflows. |
|
The script does not seem to be used after gardener#12592.
* Clean up the obsolete `.ci/set_dependency_version` script The `.ci/set_dependency_version` script is part of the [component upgrade contract](https://gardener.github.io/cc-utils/traits/update_component_deps.html). However, the gardener/gardener repository no longer uses concourse. Even before than, I am not sure if this component upgrade contract was used for the gardener/gardener repo after the introduction of Renovate for updating referenced OCI images. The `hack/.ci/set_dependency_version` script is still preserved as it is still reused by the extension repositories. See also the [ocm-upgrade action](https://github.com/gardener/cc-utils/blob/master/.github/actions/ocm-upgrade/action.yaml). * Clean up the obsolete `.ci/verify` script The script does not seem to be used after #12592.
* Clean up the obsolete `.ci/set_dependency_version` script The `.ci/set_dependency_version` script is part of the [component upgrade contract](https://gardener.github.io/cc-utils/traits/update_component_deps.html). However, the gardener/gardener repository no longer uses concourse. Even before than, I am not sure if this component upgrade contract was used for the gardener/gardener repo after the introduction of Renovate for updating referenced OCI images. The `hack/.ci/set_dependency_version` script is still preserved as it is still reused by the extension repositories. See also the [ocm-upgrade action](https://github.com/gardener/cc-utils/blob/master/.github/actions/ocm-upgrade/action.yaml). * Clean up the obsolete `.ci/verify` script The script does not seem to be used after gardener#12592.
see: https://gardener.github.io/cc-utils/github_actions.html
How to categorize this PR?
/area delivery
/kind technical-debt
/kind task
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
As GitHub-Action will only become available after merging this pullrequest, please refer to, e.g. this run for checking on the pipeline.
Release note: