This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Make check-dependent-* only be executed in PRs #4588
Merged
ordian
merged 1 commit into
paritytech:master
from
joao-paulo-parity:jp/companions-script
Dec 27, 2021
Merged
Make check-dependent-* only be executed in PRs #4588
ordian
merged 1 commit into
paritytech:master
from
joao-paulo-parity:jp/companions-script
Dec 27, 2021
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
Make check-dependent-* jobs only be executed in PRs instead of both PRs and master. Reason 1: The companion is not merged at the same time as the parent PR ([1](paritytech/parity-processbot#347 (comment))), therefore the pipeline will fail on master since the companion PR is not yet merged in the other repository. This scenario is demonstrated by the pipeline of paritytech/substrate@82cc374. Reason 2: The job can still fail on master due to a new commit on the companion PR's repository which was merged after `bot merge` happened, as demonstrated by the following scheme: 1. Parent PR is merged 2. Companion PR is updated and set to merge in the future 3. In the meantime a new commit is merged into the companion PR repository's master branch 4. The `check-dependent-*` job runs on master but, due to the new commit, it fails for unrelated reasons While "Reason 2" can be used as an argument against this PR, in that it would be useful to know if the integration is failing on master, "Reason 1" should be taken care of due to this inherent flaw of the current companion build system design.
joao-paulo-parity
added
A2-insubstantial
Pull request requires no code review (e.g., a sub-repository hash update).
B0-silent
Changes should not be mentioned in any release notes
C1-low
PR touches the given topic and has a low impact on builders.
labels
Dec 23, 2021
alvicsam
approved these changes
Dec 23, 2021
ordian
added a commit
that referenced
this pull request
Dec 27, 2021
* master: make check-dependent-* only be executed in PRs (#4588) session_info: add dispute_period and random_seed (#4547) session-info: add new fields + migration (#4545) Bump zstd from 0.9.0+zstd.1.5.0 to 0.9.1+zstd.1.5.1 (#4597) Relaunch Rococo (#4577) Companion for substrate#9732 (#4104) Better logs and metrics on PoV fetching. (#4593)
drahnr
pushed a commit
that referenced
this pull request
Jan 4, 2022
Make check-dependent-* jobs only be executed in PRs instead of both PRs and master. Reason 1: The companion is not merged at the same time as the parent PR ([1](paritytech/parity-processbot#347 (comment))), therefore the pipeline will fail on master since the companion PR is not yet merged in the other repository. This scenario is demonstrated by the pipeline of paritytech/substrate@82cc374. Reason 2: The job can still fail on master due to a new commit on the companion PR's repository which was merged after `bot merge` happened, as demonstrated by the following scheme: 1. Parent PR is merged 2. Companion PR is updated and set to merge in the future 3. In the meantime a new commit is merged into the companion PR repository's master branch 4. The `check-dependent-*` job runs on master but, due to the new commit, it fails for unrelated reasons While "Reason 2" can be used as an argument against this PR, in that it would be useful to know if the integration is failing on master, "Reason 1" should be taken care of due to this inherent flaw of the current companion build system design.
Wizdave97
pushed a commit
to ComposableFi/polkadot
that referenced
this pull request
Feb 3, 2022
Make check-dependent-* jobs only be executed in PRs instead of both PRs and master. Reason 1: The companion is not merged at the same time as the parent PR ([1](paritytech/parity-processbot#347 (comment))), therefore the pipeline will fail on master since the companion PR is not yet merged in the other repository. This scenario is demonstrated by the pipeline of paritytech/substrate@82cc374. Reason 2: The job can still fail on master due to a new commit on the companion PR's repository which was merged after `bot merge` happened, as demonstrated by the following scheme: 1. Parent PR is merged 2. Companion PR is updated and set to merge in the future 3. In the meantime a new commit is merged into the companion PR repository's master branch 4. The `check-dependent-*` job runs on master but, due to the new commit, it fails for unrelated reasons While "Reason 2" can be used as an argument against this PR, in that it would be useful to know if the integration is failing on master, "Reason 1" should be taken care of due to this inherent flaw of the current companion build system design.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
A2-insubstantial
Pull request requires no code review (e.g., a sub-repository hash update).
B0-silent
Changes should not be mentioned in any release notes
C1-low
PR touches the given topic and has a low impact on builders.
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.
Make check-dependent-* jobs only be executed in PRs instead of both PRs and master.
Reason 1: The companion is not merged at the same time as the parent PR (1), therefore the pipeline will fail on master since the companion PR is not yet merged in the other repository. This scenario is demonstrated by the pipeline of paritytech/substrate@82cc374.
Reason 2: The job can still fail on master due to a new commit on the companion PR's repository which was merged after
bot merge
happened, as demonstrated by the following scheme:check-dependent-*
job runs on master but, due to the new commit, it fails for unrelated reasonsWhile "Reason 2" can be used as an argument against this PR, in that it would be useful to know if the integration is failing on master, "Reason 1" should be taken care of due to this inherent flaw of the current companion build system design.