- Notifications
You must be signed in to change notification settings - Fork 2k
ci: use single dynamic build-test action#1339
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
nschonni left a comment
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.
This would probably also drop the https://github.com/nodejs/docker-node/blob/master/.github/workflows/dockerfiles.yml
and -c part of the update.sh file
Uh oh!
There was an error while loading. Please reload this page.
ttshivers commented Sep 27, 2020
That makes sense with dropping https://github.com/nodejs/docker-node/blob/master/.github/workflows/dockerfiles.yml. In fact, that file currently calls It doesn't look like there is a |
nschonni commented Sep 27, 2020
Right, I forgot the letter I ended up changing it to 😆 |
a20aeee to 0acdcd7Compare
nschonni left a comment
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.
Think this will probably make a good base for the expanded architecture stuff
Uh oh!
There was an error while loading. Please reload this page.
0acdcd7 to d303c17Comparettshivers commented Sep 28, 2020 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
One question I have is whether to keep around test-build.sh and test-image.bats since the GitHub test action won't use them anymore. |
nschonni commented Sep 28, 2020
I don't feel very strongly about keeping them, but I think some people liked them, so I'll see who chimes in |
SimenB left a comment
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.
One question I have is whether to keep around test-build.sh and test-image.bats since the GitHub test action won't use them anymore.
I don't feel very strongly about keeping them, but I think some people liked them, so I'll see who chimes in
I wanted to keep them as a way to run a test on the image from the outside, rather than on the inside during build. However, the tests now do docker run so I'm personally happy to remove them
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
6c8543e to aa615beCompareUh oh!
There was an error while loading. Please reload this page.
aa615be to 23ea55aCompareUh oh!
There was an error while loading. Please reload this page.
SimenB commented Oct 8, 2020
Just delete those and we can merge? 🙂 |
e98c222 to 00fd0ffComparettshivers commented Oct 8, 2020
Deleted those files |
SimenB commented Oct 12, 2020 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
Squash the commits? At least the |
02eeb6c to 92d7b18Comparettshivers commented Oct 12, 2020
The errors seem to be due to the flaky gpg servers. Should a time limit be put on tests to prevent it hanging from 6 hours (default max job time) if it fails? |
SimenB commented Oct 12, 2020
As long as we don't build node it should just be a few minutes. Probably a good idea to lower the limit, yeah |
nschonni commented Oct 12, 2020
I would thing 30minutes to 1 hour like the old Travis setup would be fine |
Add a GitHub action that dynamically generates the matrix of Dockerfiles to test based on what files have changed. This avoids having to have generated workflows for each version x variant combo. It looks for any changed Dockerfiles, or docker-entrypoint.sh. If any of the testing files are changed, it will test all Dockerfiles
92d7b18 to ee169b2Comparettshivers commented Oct 12, 2020
Added a 60 minute timeout for each matrix entry. |
BATS was initially added to this repository in nodejs#802, but was then removed in nodejs#1339. This adds it back, and hooks it up to Github Actions.
BATS was initially added to this repository in nodejs#802, but was then removed in nodejs#1339. This adds it back, and hooks it up to Github Actions. This also fixesnodejs#1583, which happened due to a bug in the "Build image" step: the build context was set to the root project directory, which meant the `COPY docker-entrypoint.sh /usr/local/bin/` instruction was copying the base `docker-entrypoint.sh` file into the Docker image instead of the one in the variant directory. Changing the context to the variant directory solves that.
Add a GitHub action that dynamically generates the matrix of Dockerfiles to test based on what files have changed. This avoids having to have generated workflows for each version x variant combo.
It looks for any changed
Dockerfiles, ordocker-entrypoint.sh. If any of the testing files are changed, it will test allDockerfiles