This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Refactor the automatic-crate-publishing logic, make triggered pipelines uninterruptible as well #13908
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
It's not neccessary to dynamically change the `interruptible` setting for *all* jobs as the old approach does; gitlab already considers a pipeline uninterruptible as soon as a single uninterruptible job has started (cf https://docs.gitlab.com/ee/ci/yaml/#interruptible). IMO this approach is more readable, as it avoids dynamically loading the .defaults section from different files based on import conditions; the logic is now shorter and entirely contained in the main .gitlab-ci.yml.
altaua
added
A2-insubstantial
alvicsam
approved these changes
Apr 13, 2023
rcny
reviewed
Apr 13, 2023
.gitlab-ci.yml
Outdated
| # * multi-project pipelines such as the ones triggered by the scripts repo | ||
| # * the scheduled automatic-crate-publishing pipeline | ||
| # | ||
| # In those cases, we add an interruptible .pre job; once that one has started, |
There was a problem hiding this comment.
we add an interruptible .pre job
AFAIU it should be we add an uninterruptible .pre job?
altaua
force-pushed
the
mira/uninterruptible-mpps
branch
from
a359e1e
to
d2b4303
Compare
rcny
approved these changes
Apr 13, 2023
15 tasks
nathanwhit
pushed a commit
to nathanwhit/substrate
that referenced
this pull request
Jul 19, 2023
…es uninterruptible as well (paritytech#13908) * Use a new approach to make automatic-crate-publishing uninterruptible It's not neccessary to dynamically change the `interruptible` setting for *all* jobs as the old approach does; gitlab already considers a pipeline uninterruptible as soon as a single uninterruptible job has started (cf https://docs.gitlab.com/ee/ci/yaml/#interruptible). IMO this approach is more readable, as it avoids dynamically loading the .defaults section from different files based on import conditions; the logic is now shorter and entirely contained in the main .gitlab-ci.yml. * Make triggered multi-project pipelines uninterruptible
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
It's not neccessary to dynamically change the
interruptiblesetting for all jobs as the old approach does; gitlab already considers a pipeline uninterruptible as soon as a single uninterruptible job has started (cf https://docs.gitlab.com/ee/ci/yaml/#interruptible).IMO this approach is more readable, as it avoids dynamically loading the
.defaultssection from different files based on import conditions; the logic is now shorter and entirely contained in the main .gitlab-ci.yml.In addition to the refactoring, this PR also adds a condition to make multi-project pipelines uninterruptible too. Currently, a substrate pipeline triggered e.g. by a ci-linux build in the scripts repo could be interrupted, thus unneccessarily preventing a
ci-linux:productiondeployment.