feat(ci): split compilation and packaging up MONGOSH-469 #536
Conversation
This file contains hidden or 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
- Split the `compile_and_upload_artifact` evergreen functions/tasks
into two steps, named `compile_artifact` and
`package_and_upload_artifact`. The former only compiles the binary,
the latter creates the tarball/pkg/deb/zip from it and uploads
it to S3.
- On the build package level, the latter is also subdivided into
creating the tarball and uploading it. This makes it easier to
perform local testing, and replaces the “dry run” mode that we
previously had.
- Run the different tasks on appropriate machines:
- On Windows and Linux, the build steps are moved to separate,
more powerful machines that are intended for compilation steps.
All other tasks remain on the same hosts. For Linux, this means
compiling the executable once and packaging it three times,
rather than compiling it three different times as well, and
faster compilation times overall.
- On macOS, the packaging step is kept on the codesign machine,
while building takes place on regular macOS hosts. This helps
us be nice to other evergreen consumers, because it reduces the
amount of time that we’re hogging the single codesign host
that evergreen provides.
- In order to move executables from the compilation to the packaging
steps, store them temporarily in S3 using evergreen’s built-in
storage mechanism.
mcasimir
reviewed
Jan 8, 2021
rose-m
reviewed
Jan 8, 2021
addaleax
changed the title
|
I think this should pass now, removing the WIP label :) |
rose-m
approved these changes
Jan 11, 2021
| fi | ||
| RELEASE_MONGOSH | ||
|
|
||
| if [ `uname` == Darwin ]; then | ||
| ssh -v -p 2222 localhost "bash ~/release_mongosh.sh" |
There was a problem hiding this comment.
Independent from the PR: but why is there this ssh command on Mac? 🤔
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
compile_and_upload_artifactevergreen functions/tasksinto two steps, named
compile_artifactandpackage_and_upload_artifact. The former only compiles the binary,the latter creates the tarball/pkg/deb/zip from it and uploads
it to S3.
creating the tarball and uploading it. This makes it easier to
perform local testing, and replaces the “dry run” mode that we
previously had.
more powerful machines that are intended for compilation steps.
All other tasks remain on the same hosts. For Linux, this means
compiling the executable once and packaging it three times,
rather than compiling it three different times as well, and
faster compilation times overall.
while building takes place on regular macOS hosts. This helps
us be nice to other evergreen consumers, because it reduces the
amount of time that we’re hogging the single codesign host
that evergreen provides.
steps, store them temporarily in S3 using evergreen’s built-in
storage mechanism.