Adjust release flows to use those with the new branch model #5015
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nto ep-adjsut-pipeline-to-use-stable
alvicsam
approved these changes
Jul 15, 2024
Morganamilo
approved these changes
Jul 17, 2024
AndWeHaveAPlan
approved these changes
Jul 17, 2024
Merged
via the queue into
paritytech:master
with commit Jul 17, 2024
7399519
155 of 160 checks passed
paritytech-ci
pushed a commit
that referenced
this pull request
Jul 17, 2024
This PR contains adjustments of the node release pipelines so that it will be possible to use those to trigger release actions based on the `stable` branch. Previously the whole pipeline of the flows from [creation of the `rc-tag`](https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/release-10_rc-automation.yml) (v1.15.0-rc1, v1.15.0-rc2, etc) till [the release draft creation](https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/release-30_publish_release_draft.yml) was triggered on push to the node release branch. As we had the node release branch and the crates release branch separately, it worked fine. From now on, as we are switching to the one branch approach, for the first iteration I would like to keep things simple to see how the new release process will work with both parts (crates and node) made from one branch. Changes made: - The first step in the pipeline (rc-tag creation) will be triggered manually instead of the push to the branch - The tag version will be set manually from the input instead of to be taken from the branch name - Docker image will be additionally tagged as `stable` Closes: paritytech/release-engineering#214
jpserrat
pushed a commit
to jpserrat/polkadot-sdk
that referenced
this pull request
Jul 18, 2024
…ch#5015) This PR contains adjustments of the node release pipelines so that it will be possible to use those to trigger release actions based on the `stable` branch. Previously the whole pipeline of the flows from [creation of the `rc-tag`](https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/release-10_rc-automation.yml) (v1.15.0-rc1, v1.15.0-rc2, etc) till [the release draft creation](https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/release-30_publish_release_draft.yml) was triggered on push to the node release branch. As we had the node release branch and the crates release branch separately, it worked fine. From now on, as we are switching to the one branch approach, for the first iteration I would like to keep things simple to see how the new release process will work with both parts (crates and node) made from one branch. Changes made: - The first step in the pipeline (rc-tag creation) will be triggered manually instead of the push to the branch - The tag version will be set manually from the input instead of to be taken from the branch name - Docker image will be additionally tagged as `stable` Closes: https://github.com/paritytech/release-engineering/issues/214
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this pull request
Aug 2, 2024
…ch#5015) This PR contains adjustments of the node release pipelines so that it will be possible to use those to trigger release actions based on the `stable` branch. Previously the whole pipeline of the flows from [creation of the `rc-tag`](https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/release-10_rc-automation.yml) (v1.15.0-rc1, v1.15.0-rc2, etc) till [the release draft creation](https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/release-30_publish_release_draft.yml) was triggered on push to the node release branch. As we had the node release branch and the crates release branch separately, it worked fine. From now on, as we are switching to the one branch approach, for the first iteration I would like to keep things simple to see how the new release process will work with both parts (crates and node) made from one branch. Changes made: - The first step in the pipeline (rc-tag creation) will be triggered manually instead of the push to the branch - The tag version will be set manually from the input instead of to be taken from the branch name - Docker image will be additionally tagged as `stable` Closes: https://github.com/paritytech/release-engineering/issues/214
sfffaaa
pushed a commit
to peaqnetwork/polkadot-sdk
that referenced
this pull request
Dec 27, 2024
…ch#5015) This PR contains adjustments of the node release pipelines so that it will be possible to use those to trigger release actions based on the `stable` branch. Previously the whole pipeline of the flows from [creation of the `rc-tag`](https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/release-10_rc-automation.yml) (v1.15.0-rc1, v1.15.0-rc2, etc) till [the release draft creation](https://github.com/paritytech/polkadot-sdk/blob/master/.github/workflows/release-30_publish_release_draft.yml) was triggered on push to the node release branch. As we had the node release branch and the crates release branch separately, it worked fine. From now on, as we are switching to the one branch approach, for the first iteration I would like to keep things simple to see how the new release process will work with both parts (crates and node) made from one branch. Changes made: - The first step in the pipeline (rc-tag creation) will be triggered manually instead of the push to the branch - The tag version will be set manually from the input instead of to be taken from the branch name - Docker image will be additionally tagged as `stable` Closes: paritytech/release-engineering#214
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains adjustments of the node release pipelines so that it will be possible to use those to trigger release actions based on the
stablebranch.Previously the whole pipeline of the flows from creation of the
rc-tag(v1.15.0-rc1, v1.15.0-rc2, etc) till the release draft creation was triggered on push to the node release branch. As we had the node release branch and the crates release branch separately, it worked fine.From now on, as we are switching to the one branch approach, for the first iteration I would like to keep things simple to see how the new release process will work with both parts (crates and node) made from one branch.
Changes made:
stableCloses: https://github.com/paritytech/release-engineering/issues/214