Introduce a Dependency Checker to trigger new Docker Builds on main #424
Conversation
|
The documentation is not available anymore as the PR was closed or merged. |
There was a problem hiding this comment.
Great check! Left a comment about why we check setup on pull_request.
Thank you, @muellerzr !
Would be nice if you can test this PR works expected (change setup.py, for example). You might need to create a branch like test_ci_XXX, and modify the workflow files to be triggered on the experimentation branch(es). This is just a suggestion though.
(sorry, I guess I am the one who freaks out, haha)
|
|
||
| build-docker-containers: | ||
| needs: check-for-setup | ||
| if: (github.event_name == 'push') && (needs.check-for-setup.outputs.changed == '1') |
There was a problem hiding this comment.
Very nice - we should build the image only for the push event (to main).
There was a problem hiding this comment.
Yeah, I meanly mean push in this remark, and you are doing it as what I would expect. (to main is to make it more clear only 馃槃 )
| workflow_run: | ||
| workflows: ["Check for dependency modification"] | ||
| branches: ["main"] | ||
| types: [completed] |
There was a problem hiding this comment.
I was thinking that completed means the CI will be run only if the workflow Check for dependency modification is successful.
After reading this doc, it is not the case. And this is good, as we want to run the push CI anyway (even if something wrong in the setup check).
|
@ydshieh you can see my almost 250 debug logs here: https://github.com/muellerzr/accelerate/actions Very very comfortable with this working |
Introduce a Dependency Checker to trigger new Docker Builds on main
What does this add?
This PR introduces a new workflow that will do a few things:
setup.pywas adjusted in a pull requestbuild-docker-imagesto be triggered by aworkflow_call, allowingcheck_dependenciesto trigger iton-mergeworkflow to be triggered on main by the completion ofcheck_setup, rather than a push directly. This will ensure that the tests will be passing on main if a new version of anything is introduced with the other runners + nightliesWhy is it needed?
A very annoying frustration I've seen over the last few months in the transformers repo is people freaking out when the runners are a failure, due to a new dependency introduced. This solves this problem, and I'll be building a similar workflow for transformers on Monday. (This was just the "test")
cc @ydshieh as this'll be coming to transformers afterwards 馃槈