-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
While you are at it, do you think it would be possible to include BEEFY as well? Please!! 😄 |
since you asked nicely ;) |
5e44cc5
to
5f05ce8
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.
When there is a polkadot companion, you will also need to overwrite polkadot in cumulus to use this companion. As otherwise it will fail to build
33c68bb
to
c3a1648
Compare
c3a1648
to
00a925b
Compare
.gitlab-ci.yml
Outdated
variables: | ||
COMPANION_ORG: paritytech | ||
COMPANION_REPO: cumulus | ||
COMPANION_BUILD: "cargo check" |
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.
Hmm this isn't really great :P I can understand why you are doing this, but honestly I don't know...
Overall it would be nice to have pre merge checks that runs the entire test suite of cumulus to make sure we don't break anything..
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.
You mean it's better to trigger the entire cumulus CI here? Is it worth doing on every commit? Maybe on some certain files/dirs changes at least?
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.
I mean for cumulus it is not that important at the moment. A cargo test --all --release
would do it as well. However, even that takes some time. I would actually like to have this as a precommit check, but we don't have support for this :(
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.
yeah, we're kinda stuck between not being able to use the existing tools for pre-merge pipelines and the inability to use some kind of a pre-commit tool with github.com. This means we'll be looking into how to deal with it nicely, but currently, we're scaling vertically.
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.
I suggest we could generalize these checks by actually triggering the CIs of the relevant repository. As we've been doing it with Simnet recently. This script passes overriding variables to the downstream CI and returns the status of all checks.
It will require some changes in the relevant repos, (with which @paritytech/ci will certainly help), but will be more future-proof.
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, this triggering script looks like this, it's a bit more specialized for Simnet.
.gitlab-ci.yml
Outdated
variables: | ||
COMPANION_ORG: paritytech | ||
COMPANION_REPO: cumulus | ||
COMPANION_BUILD: "cargo check" |
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.
COMPANION_BUILD: "cargo check" | |
COMPANION_BUILD: "cargo check --benches --all --tests" |
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.
How about cargo check --all-targets --workspace
?
--all
is deprecated in favour of --workspace
https://doc.rust-lang.org/cargo/commands/cargo-check.html
--all-targets
= --lib --bins --tests --benches --examples
.gitlab-ci.yml
Outdated
variables: | ||
COMPANION_ORG: paritytech | ||
COMPANION_REPO: grandpa-bridge-gadget | ||
COMPANION_BUILD: "cargo check" |
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.
COMPANION_BUILD: "cargo check" | |
COMPANION_BUILD: "cargo check --benches --all --tests" |
|
||
pr_body="$(sed -n -r 's/^[[:space:]]+"body": (".*")[^"]+$/\1/p' "${pr_data_file}")" | ||
|
||
echo "${pr_body}" | sed -n -r \ |
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.
Does sed account for newlines in the JSON string?
This probably never happens but you might have a comment like this:
Something something companion
Bla bla another pull request: https://github.com/foo/pull/1
As I understand it, since you're not matching [Cc]ompanion: [regex]
all in the same line, that comment would be detected although it should not be.
Using echo -e
will output the JSON newlines as actual newlines so you'll be able to match it line-by-line.
#shellcheck source=../common/lib.sh | ||
. "$(dirname "${0}")/../common/lib.sh" | ||
|
||
ORGANISATION=$1 |
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.
nit: Apparently "Organisation" is valid spelling in British English but IMO it'd look better ORGANIZATION
if expr match "${CI_COMMIT_REF_NAME}" '^[0-9]\+$' >/dev/null | ||
then | ||
boldprint "this is pull request no ${CI_COMMIT_REF_NAME}" | ||
pr_companion="$(get_companion "paritytech/substrate" "$CI_COMMIT_REF_NAME" "$ORGANISATION/$REPO")" |
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.
I think I get why "paritytech/substrate" is hardcoded for now (because this script is only used in this repository at the moment?) but it'd be good to have this as another variable for clarity's sake
diener_commands["paritytech/grandpa-bridge-gadget"]='--beefy' | ||
|
||
for dep in "${DEPS[@]}"; do | ||
dep_companion="$(get_companion "paritytech/substrate" "$CI_COMMIT_REF_NAME" "$dep")" |
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.
since you're already fetching the description once in the lines above, it would be good to reuse it instead of making more API requests
git -C "$dep" checkout "pr/${dep_companion}" | ||
git -C "$dep" merge origin/master | ||
# Tell this dependency to use the version of substrate in this PR | ||
diener patch --crates-to-patch "$SUBSTRATE_DIR" --substrate --path "$dep/Cargo.toml" |
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.
SUBSTRATE_DIR
and --substrate
will have a rework to be dynamic once this script is made more general, right?
fi | ||
|
||
# Test pr or master branch with this Substrate commit. | ||
diener patch --crates-to-patch ".." --substrate --path "Cargo.toml" |
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.
Changing this ".." to "$SUBSTRATE_DIR" makes the script less confusing to follow. It makes sense because you're doing cd
at the start but it's not immediately obvious which is the current directory when this line is reached.
git fetch --depth 100 origin | ||
git merge origin/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.
can it just be git pull origin master
? I don't quite get the depth numbers but fetching a single branch is better than doing fetch origin
(which fetches everything)
boldprint "companion pr specified/detected: #${pr_companion}" | ||
git fetch origin "refs/pull/${pr_companion}/head:pr/${pr_companion}" | ||
git checkout "pr/${pr_companion}" | ||
git merge origin/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.
This should be merging whatever branch the PR is currently targetting instead of master (although PRs usually target master). Perhaps it doesn't need to be handled at the moment, but a FIXME
note about this detail would be welcome.
git clone --depth 20 "https://github.com/$dep.git" "$dep" | ||
git -C "$dep" fetch origin "refs/pull/${dep_companion}/head:pr/${dep_companion}" | ||
git -C "$dep" checkout "pr/${dep_companion}" | ||
git -C "$dep" merge origin/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.
diener_commands["paritytech/substrate"]='--substrate' | ||
diener_commands["paritytech/grandpa-bridge-gadget"]='--beefy' | ||
|
||
for dep in "${DEPS[@]}"; do |
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.
If https://github.com/paritytech/substrate/pull/9010/files#r660727553 is taken care of, you could try to get rid of this $DEPS
and just loop through all companion lines in the description; and if some repository is not supported (might be typo) then just fail the script.
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
FYI a critical bug was found in #9677 (comment). I think it's grave enough to warrant implementing a fix in a separate PR and then rebase this on top of the fix PR. |
FYI I've asked @s3krit to let me take over this effort. I would like to merge #9721 before moving to this since the changes over there are simpler and the implementation should be finished, right now it's simply waiting for the CI image to be updated (paritytech/scripts#309). |
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Adds companion builds to ensure we don't break cumulus & grandpa-bridge-gadget repos.
Actually builds out a generic companion-build script which takes a repo and organisation (& an optional build string) as an argument. Initially for cumulus and beefy we just run a
cargo check
but I'm open to changing that to something more appropriate if we feel that would be useful.We can also specify additional dependencies. Consider the case of Cumulus:
There will be a followup PR that breaks this out into another repo so we can add companion builds to other projects that have dependents we don't want to break, but baby steps :)
Initially, we're almost definitely going to have some teething problems with this PR so I don't want the statuses to be required yet... that can come later.
NOTE: For the companion to be properly detected, you need to comment with the actual name of the repo (see below's beefy companion - you can't just put 'beefy companion:')
Closes: https://github.com/paritytech/ci_cd/issues/139
Polkadot companion: paritytech/polkadot#3379
Cumulus companion: paritytech/cumulus#518
grandpa-bridge-gadget companion: paritytech/grandpa-bridge-gadget#223