-
Notifications
You must be signed in to change notification settings - Fork 5
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 model workflow to use external workflow defined in ccao-data/actions
#59
Refactor model workflow to use external workflow defined in ccao-data/actions
#59
Conversation
950e448
to
953219f
Compare
953219f
to
9392c55
Compare
cc52be7
to
e04d52e
Compare
e04d52e
to
86729e1
Compare
…b-deploy workflow
d125b08
to
5030512
Compare
5030512
to
e3320d7
Compare
e3320d7
to
d61e064
Compare
name: build-and-run-model | ||
|
||
on: | ||
pull_request: | ||
types: [opened, reopened, synchronize, closed] |
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.
Per the docs, opened
, reopened
, and closed
are the default enabled event types when pull_request
is enabled without a types
attribute (as was the case before this PR). Now that the build-and-run-batch-job
workflow supports running a cleanup step on the closed
event (see docs here), we need to specify all of the previously-implicit event types in order to add closed
to the list.
@@ -26,12 +27,11 @@ jobs: | |||
# required in order to allow the reusable called workflow to push to | |||
# GitHub Container Registry | |||
packages: write | |||
uses: ./.github/workflows/build-and-run-batch-job.yaml | |||
uses: ccao-data/actions/.github/workflows/build-and-run-batch-job.yaml@master |
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.
While it would be better to pin to a specific release of ccao-data/actions
, my thinking is that it makes sense to pin to master
while we're iterating quickly, and then pin to a tag once things are feeling stable.
Alternatively, we could pin to a specific commit SHA instead, but we won't know what that SHA is until ccao-data/actions#1 gets merged.
ccao-data/actions
workflowsccao-data/actions
a2b242c
to
568b8aa
Compare
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.
@jeancochrane This is absolutely awesome! Super clean implementation. I can't wait to really test it out with some runs.
* Pin build-and-run-batch-job to branch that fixes Terraform configs * Delete terraform directory that has been unused since #59 * Lower resource requirements in build-and-run-model to test changing job definition * Add missing ref, which is necessary when testing a different branch of ccao-data/actions * Switch build-and-run-model params back to their usual values after testing
This PR updates the
build-and-run-model
workflow to point to the reusablebuild-and-run-batch-job
workflow defined in ccao-data/actions#1. In the process, it removes a number of extraneous files that are now being managed by the external workflow:setup-terraform
actionpoll_batch_job_script.sh
scriptcleanup-model
andcleanup-terraform
workflows, which are now included as part of thecleanup
step inbuild-and-run-batch-job
.Connects ccao-data/model-condo-avm#5.
Testing
build
andtest
jobs of thebuild-and-run-model
workflow, see this workflow runrun
job fails, but only because I terminated the Batch job before it would complete; once the workflow gets to the point where it's polling the status of the Batch job, we can be confident that the test has passed, since nothing in the model pipeline itself has changed in this PRcleanup
job of thebuild-and-run-model
workflow, see this workflow run