-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Refactor Azure Pipelines config and tweak releases #244
Refactor Azure Pipelines config and tweak releases #244
Conversation
10a8d35
to
ff09f08
Compare
Er sorry I botched the commit message and opened this PR with the wrong title, now the PR/description match the intended purpose! |
5d05220
to
9a7bd2d
Compare
Ok CI looks good here, although I'd like to test out the artifacts to make sure they've got the intended directory structure. |
Thank you for doing these cleanups!
I haven't yet looked at the PR in detail, but I did quickly look at the artifacts in the Pipelines artifacts explorer. I see two issues:
I'll look at the actual diff tomorrow. |
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 all looks great!
Apart from the issues mentioned below, I do have one concern: this eliminates all test coverage of release builds. While for the time being it doesn't seem extremely likely that we'd run into issues that only occur in release builds, if we did we'd find out much later. Also, it seems unfortunate not to test the bits that we're actually shipping. Hence, I'd prefer if we did include that test coverage still.
.azure-pipelines.yml
Outdated
condition: and(succeeded(), ne( variables['Agent.OS'], 'Windows_NT' ), eq( variables['build_type'], 'release' )) | ||
set -e | ||
mkdir -p $BUILD_BINARIESDIRECTORY/$BASENAME | ||
if [ "$AGENT_OS" = "windows" ]; then |
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 is, of course, much better! :)
7025fa0
to
6c29695
Compare
Ok I think the tarballs are good to go now. I've pushed a final commit to remove a few more wip comments but it's the same config files as the last build which had successful artifacts that are all structured right |
@alexcrichton @tschneidereit this is slightly off-topic however not all irrelevant, I've seen you guys use "cc" and "r?" in this repo and |
I would personally consider it overkill in the sense that bors is best for when CI takes a long time, but the CI for both these repos is pretty speedy. |
Roger that :-) |
@alexcrichton, see my comment about test coverage. Is there a reason why losing test coverage for release builds wouldn't be an issue? |
Oh oops sorry totally missed that, agreed on that point and I'll add that back in. |
6c29695
to
6c54e17
Compare
* Extract out doc/rustfmt jobs into their own separate builders. Helps avoiding having to skip tons of steps and can get failing results more quickly. * Extract out Rust installation logic to a dedicated template. * Separate out the build/test job matrices, where one matrix runs tests and another runs a full build * Refactor release directory structure to follow a convention where `foo.tar.gz` extracts to a folder called `foo` and follow unix-like conventions and copy over the license/readme files into the release tarballs.
6c54e17
to
24943c1
Compare
Ok should be good to go! |
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.
Looks great!
The one thing to change is the order of tests and builds for release.
* Applies all clippy suggestions In a few cases a clippy annotation was provided to ignore the clippy warning. * apply rustfmt * make wasmi compiler under no_std again * use rustfmt +stable
Use "main" instead of start function
Extract out doc/rustfmt jobs into their own separate builders. Helps
avoiding having to skip tons of steps and can get failing results more
quickly.
Extract out Rust installation logic to a dedicated template.
Separate out the build/test job matrices, where one matrix runs tests
and another runs a full build
Refactor release directory structure to follow a convention where
foo.tar.gz
extracts to a folder calledfoo
and follow unix-likeconventions and copy over the license/readme files into the release
tarballs.