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
CI: Re-write run_task.sh
#2633
CI: Re-write run_task.sh
#2633
Conversation
Pull Request Test Coverage Report for Build 8840820999Details
💛 - Coveralls |
5daeab2
to
c67d916
Compare
WASM fail needs further investigation with fresh eyes. |
da0b9a3
to
503bbb7
Compare
Bizzare, I can't work out why the wasm test has stopped working, I also can't get it running right now on this branch or |
503bbb7
to
62fdf77
Compare
62fdf77
to
27e2b58
Compare
Needs rebase after #2635. |
36cea30
to
a101daa
Compare
Needs #2637 |
661599d
to
0c9e1dd
Compare
Wow, this re-write uncovered a bunch of bugs in CI. Oh and the chat bot led me on a lot of wild goose chases, its good but it talks a lot of nonsense. (raised #2638) |
0c9e1dd
to
03276f0
Compare
68d38c0
to
39f23d9
Compare
contrib/run_task.sh
Outdated
build_and_test() { | ||
# Building the fuzz crate is more-or-less just a sanity check. | ||
# pushd "$REPO_DIR/fuzz" > /dev/null | ||
# cargo --locked build |
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.
In 39f23d9:
If we are going to comment these out we might as well just remove them.
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.
Ah that's a fail while testing the script yesterday. Big diffs are bad even for the developer :)
Changes in force push:
|
39f23d9
to
9e70d85
Compare
More changes, try even harder to document exactly whats going on in the script, bash hides bugs real easy. |
9e70d85
to
f3e028f
Compare
Trivial changes to |
OMG, the wasm test is not actually running, the
|
ba57bac
to
c48865a
Compare
I am continuing to be puzzled by why the WASM test fails here and not without this PR, a random example is #2686
Yet the installed packages differ dramatically (eg |
1dd98b2
to
eb9130b
Compare
BOOM! I finally found the bug! We are not using the Since we patch the |
Recently we re-wrote CI to increase VM level parallelism, in hindsite this has proved to be not that great because: - It resulted in approx 180 jobs - We are on free tier so only get 20 jobs (VMs) at a time so its slow to run - The UI is annoying to dig through the long job list to find failures Have another go at organising the jobs with the main aim of shortening total run time and making it easier to quickly see fails. Re-write the `run_task.sh` script, notable moving manifest handling to the workflow. Also don't bother testing with beta toolchain. WASM Note Removes the `cdylib` and `rlib` from the manifest patching during wasm build - I do not know the following: - Why this breaks on this PR but not on other PRs - Why I can't get wasm test to run locally on master but PRs are passing - What the `cdylib` and `rlib` were meant to be doing This is the docs from: https://doc.rust-lang.org/reference/linkage.html * --crate-type=cdylib, #![crate_type = "cdylib"] - A dynamic system library will be produced. This is used when compiling a dynamic library to be loaded from another language. This output type will create *.so files on Linux, *.dylib files on macOS, and *.dll files on Windows. * --crate-type=rlib, #![crate_type = "rlib"] - A "Rust library" file will be produced. This is used as an intermediate artifact and can be thought of as a "static Rust library". These rlib files, unlike staticlib files, are interpreted by the compiler in future linkage. This essentially means that rustc will look for metadata in rlib files like it looks for metadata in dynamic libraries. This form of output is used to produce statically linked executables as well as staticlib outputs.
eb9130b
to
26b9782
Compare
Yes. We can have a separate lockfile for wasm stuff if you think it'd help but we don't want to poison (and more than double) our real lockfiles. Awesome that you tracked this down :) |
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.
ACK 26b9782
Will be able to one-ACK merge in 12 days, assuming no comments, questions or NACKs. I am starting the 2-week counter from the most recent force-push because there were significant changes before then and because CI was failing which I suspect was discouraging reviewers. (Personally I had the tab open, intending to help investigate the WASM thing, for at least the last 2 weeks, and did nothing..) |
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.
ACK 26b9782.
This is a superficial review. I only checked we are not missing any checks in the new rewrite. Btw, why does the UI say 21 checks instead of 20?
I counted the |
Recently we re-wrote CI to increase VM level parallelism, in hindsite this has proved to be not that great because:
Have another go at organising the jobs with the main aim of shortening total run time and making it easier to quickly see fails.
Re-write the
run_task.sh
script, notable moving manifest handling to the workflow. Also don't bother testing with beta toolchain.Note on review
The diff is hard to read for
rust.yml
, I tried splitting out a bunch of separate patches but it resulted in the same thing (because there are so many identical lines in the yaml file). I suggest just looking at the yaml file and not the diff.