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

Improve nightly build and deployment logic #3164

Merged
merged 33 commits into from
Dec 20, 2023
Merged

Conversation

zaneselvans
Copy link
Member

@zaneselvans zaneselvans commented Dec 15, 2023

Overview

  • Remove minor versions from the GHA we depend on to minimize dependabot churn.
  • Remove the logic that was updating conda lockfiles on push.
  • Purge old files from distribution paths before uploading new outputs. This prevents stale files from hanging around after we change the name of a file.
  • Tag commits that are used for nightly builds.
  • Update stable branch to point at newly tagged release
  • Update nightly branch to point at newly successful nightly build tag.
  • Simplify Dockerfile / make it more internally consistent

Issues / Questions:

  • The nightly build jank continues. We need to dedicate some resources to consolidating it!

Part of #3140

@zaneselvans zaneselvans requested a review from jdangerx December 15, 2023 18:55
@zaneselvans zaneselvans added the nightly-builds Anything having to do with nightly builds or continuous deployment. label Dec 15, 2023
@zaneselvans zaneselvans self-assigned this Dec 15, 2023
Copy link
Member

@jdangerx jdangerx left a comment

Choose a reason for hiding this comment

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

Stoked for this to get in, I think probably making a limited bot token makes the most sense for auth!

.github/workflows/build-deploy-pudl.yml Outdated Show resolved Hide resolved
@zaneselvans zaneselvans changed the title Tag commits of nightly builds and last stable release. Improve nightly build and deployment logic Dec 19, 2023
@zaneselvans zaneselvans requested a review from jdangerx December 19, 2023 01:33
Copy link
Member Author

@zaneselvans zaneselvans left a comment

Choose a reason for hiding this comment

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

I've got something here in all the places I think we'd need to update to get the build and release tagging working:

  • vYYYY.MM.DD tags are created manually.
  • nightly-YYYY-MM-DD tags are created by the workflow, before the build is kicked off.
  • The nightly branch (which is currently a tag) has to be updated from within the Docker container, but we don't currently have a git repo inside the Docker container.
  • The stable branch (also currently a tag) will be updated by the release workflow.

Questions in review comments.

.github/workflows/pytest.yml Outdated Show resolved Hide resolved
.github/workflows/build-deploy-pudl.yml Outdated Show resolved Hide resolved
.github/workflows/release.yml Outdated Show resolved Hide resolved
.pre-commit-config.yaml Outdated Show resolved Hide resolved
.github/workflows/update-conda-lockfile.yml Outdated Show resolved Hide resolved
docker/gcp_pudl_etl.sh Outdated Show resolved Hide resolved
docker/gcp_pudl_etl.sh Outdated Show resolved Hide resolved
.github/workflows/build-deploy-pudl.yml Show resolved Hide resolved
.github/workflows/build-deploy-pudl.yml Show resolved Hide resolved
Comment on lines 37 to 44
- name: Tag nightly build
if: ${{ (github.event_name == 'schedule') }}
run: |
git config user.email "[email protected]"
git config user.name "PudlBot"
git tag -a -m "$NIGHTLY_TAG" $NIGHTLY_TAG $GITHUB_REF
git push origin $NIGHTLY_TAG

Copy link
Member Author

Choose a reason for hiding this comment

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

I think this is doing what we want it to now. It's a tag, it's applied to the branch that we're going to build (not main which is checked out here).

Copy link
Member

Choose a reason for hiding this comment

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

Sweet! Just to get this straight: we are tagging whatever this build gets kicked off on. Since this only triggers on schedule, and GITHUB_REF gets munged to dev in that case, we will always be tagging whatever the latest dev is with nightly-build-202x-xx-xx.

And then, when the nightly build succeeds, we can tell the nightly branch to point at nightly-build-202x-xx-xx and everyone who downloads the most recent nightly build off AWS will know that that corresponds to the nightly branch. But if they want to download nightly-build-202x-xx-xx from AWS they will also be able to associate that with the nightly-build-202x-xx-xx tag.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think that's close, except that we only distribute the most recent nightly build and tagged releases to AWS. I imagine we would also have a copy of the most recent release in a stable/ directory. So if you want to refer to nightly-202x-xx-xx you would need to look at the gs://builds.catalyst.coop/nightly-202x-xx-xx path where the last 30 days of nightly build outputs are stashed, regardless of whether they were successful or not. So if you want to look at nightly build outputs + the code that generated them, you can look at the GCS output, and the tagged commit that matches its name.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, right - that makes sense! Are there any barriers to distributing a few recent nightly builds on AWS as well as GCS?

Copy link
Member Author

Choose a reason for hiding this comment

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

We have a limited storage quota on AWS, and I don't think we actually want the public looking at our nightly build outputs, which may or or may not correspond to successful runs.

Copy link
Member Author

@zaneselvans zaneselvans left a comment

Choose a reason for hiding this comment

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

@jdangerx Tried to implement the merge-tag-into-branch thing here and cleaned up the Dockerfile a bit. My attempt to test the git authentication from within the container failed though.

.github/workflows/build-deploy-pudl.yml Show resolved Hide resolved
.github/workflows/release.yml Show resolved Hide resolved
docker/Dockerfile Show resolved Hide resolved
docker/Dockerfile Outdated Show resolved Hide resolved
docker/Dockerfile Show resolved Hide resolved
docker/Dockerfile Show resolved Hide resolved
docker/gcp_pudl_etl.sh Show resolved Hide resolved
docker/gcp_pudl_etl.sh Show resolved Hide resolved
docker/gcp_pudl_etl.sh Outdated Show resolved Hide resolved
docker/gcp_pudl_etl.sh Outdated Show resolved Hide resolved
@zaneselvans
Copy link
Member Author

I went ahead and created nightly and stable branches and a recently nightly-2023-12-19 tag where they would currently be, so that if this stuff runs it finds them.

@zaneselvans zaneselvans removed the request for review from bendnorman December 20, 2023 13:40
docker/gcp_pudl_etl.sh Outdated Show resolved Hide resolved
- Remove ad-hoc test of nightly build tagging
- Use "$DOUBPLE_QUOTES" around envvars to prevent globbing/split words
- Use $BUILD_ID consistently when referring to nightly build outputs.
- Update name of epacems directory that we remove before deployment.
@zaneselvans
Copy link
Member Author

@jdangerx Cleaned up the build script to remove ad-hoc tests. Integrated some of the bugfixes from #3171 here and extended them into the build script -- we construct a single $BUILD_ID in the workflow now and pass it in to the container, rather than reconstructing the ID in different ways in different places leading to broken URLs etc...

Copy link
Member

@jdangerx jdangerx left a comment

Choose a reason for hiding this comment

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

Just one blocking question about the datasette build trigger. I think we can knock out like half of #3140 in one PR though once this gets merged!

.github/release.yml Outdated Show resolved Hide resolved
docker/Dockerfile Outdated Show resolved Hide resolved
docker/Dockerfile Show resolved Hide resolved
docker/gcp_pudl_etl.sh Show resolved Hide resolved
@zaneselvans zaneselvans marked this pull request as ready for review December 20, 2023 21:10
@zaneselvans zaneselvans enabled auto-merge (squash) December 20, 2023 21:18
@zaneselvans zaneselvans merged commit a0dcdf3 into main Dec 20, 2023
14 checks passed
@zaneselvans zaneselvans deleted the tag-nightly-stable branch December 20, 2023 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
nightly-builds Anything having to do with nightly builds or continuous deployment.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants