Skip to content
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

automated ghc-lib build #6188

Merged
merged 2 commits into from
Jun 4, 2020
Merged

automated ghc-lib build #6188

merged 2 commits into from
Jun 4, 2020

Conversation

garyverhaegen-da
Copy link
Contributor

This PR aims at automating the build of ghc-lib. The current process still has a few manual steps; it needs to be updated because Bintray is going away, so this seemed like a good opportunity to fully automate it.

This works like the "patch bazel on Windows" jobs: the filename will contain a hash of the ci/da-ghc-lib folder, and the job will run only if the corresponding filename does not yet exist on the GCS bucket. PRs aiming at changing the ghc-lib version will need to run twice: once to create the artifacts, and once to change the stack-snapshot.yaml file to match.

CHANGELOG_BEGIN
CHANGELOG_END

@garyverhaegen-da garyverhaegen-da force-pushed the da-ghc-lib-gcs branch 5 times, most recently from 5c47b6d to 73730af Compare June 2, 2020 15:49
@garyverhaegen-da
Copy link
Contributor Author

This seems to work. My remaining concerns are:

  • Should this add some sort of check that stack-snapshot.yaml has indeed been updated to the correct values?
  • Should this be trying to ensure the referenced commits don't disappear? (e.g. check they are on master, add tags, ...?)

@garyverhaegen-da garyverhaegen-da marked this pull request as ready for review June 2, 2020 16:30
@garyverhaegen-da garyverhaegen-da marked this pull request as draft June 2, 2020 16:30
@garyverhaegen-da garyverhaegen-da marked this pull request as ready for review June 2, 2020 16:30
Copy link
Contributor

@cocreature cocreature left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks for taking care of this!

@ghost ghost requested review from a user and removed request for SamirTalwar June 3, 2020 07:30
Comment on lines 26 to 27
if [ "200" = "$(curl -Is "$URL_BASE/$LIB" | head -1 | awk '{print $2}')" ] \
&& [ "200" = "$(curl -Is "$URL_BASE/$PARSER" | head -1 | awk '{print $2}')" ]; then
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth extracting the calls to curl | head | awk. If either of those fails due to a network connectivity issue (as opposed to printing "404"), I think we'd probably want to abort.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, I think. Is this what you had in mind? Cursory testing in a shell does seem to indicate this would fail as expected, whereas the previous version wouldn't, as you suggested.

I've also added a -n to the gsutil cp commands so that even if we do end up running this when not needed, we would not overwrite the files.

This PR aims at automating the build of ghc-lib. The current process
still has a few manual steps; it needs to be updated because Bintray is
going away, so this seemed like a good opportunity to fully automate it.

This works like the "patch bazel on Windows" jobs: the filename will
contain a hash of the `ci/da-ghc-lib` folder, and the job will run only
if the corresponding filename does not yet exist on the GCS bucket. PRs
aiming at changing the ghc-lib version will need to run twice: once to
create the artifacts, and once to change the `stack-snapshot.yaml` file
to match.

CHANGELOG_BEGIN
CHANGELOG_END
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants