feat: GitHub Actions docker files CI

[nschonni]

Took @LaurentGoderre approach to the update.sh script generating out the Travis-CI file and converted it to create separate GitHub Actions.

• The benefit of this over the Travis diff checking, is the path approach limits the matrix to only queue jobs when a particular Dockerfile is touched.
• I added the DO NOT MERGE to this because I included a junk commit at the end to show the matrix getting triggered when the files are touched.
• This does not convert the existing deploy setup from Travis-CI
• Needed to remove the -it flag from the BATS testing since that doesn't seem to work on Actions
• Does not remove the CI job when a variant/version is removed currently. EX: like the 8 EOL

[SimenB]

This is super exciting! 😀 We need to move the deploy as well (or keep the current test runs as well until we're ready to drop travis) - now deploy will run even if a test fails. It only runs on master, and I think we're unable to merge if any steps fail, but I'd like to be safe

[nschonni]

Right now, the targets are only setup to run on pull_request and not push, so there aren't any tests for the master push.
The only think I think might make sense to go with this would be to enable the repo setting of "branch is up to date". EX: you get the annoying "Update" button when ever a different PR is merged, but then only things tested agains master can land.

[LaurentGoderre]

With this, we loose the ability to build branches and there's no longer a build on merges?

[LaurentGoderre]

I like the approach but I think it still should merge on branches and merges.

[nschonni]

They rules could be changed to run on master, but I think making the branch "strict" https://help.github.com/en/github/administering-a-repository/types-of-required-status-checks would give the same result. It's less of an issue with hitting the "Update" button with this, since only affected images would rebuilt, rather than all the jobs

[nschonni]

I've popped off the testing commit so this can land if there is agreement

[nschonni]

@LaurentGoderre I added back the build on push for now, since the publish script is relying on the merge commit right now. Also added the build and test scripts as triggers for the testing. It caught my Chakracore mistake, and I've added the patch here if it doesn't land in 13.11 PR first

[LongLiveCHIEF]

What mechanism are you guys using to actually push images to docker hub? I've seen you mention travis, but when I look at the script in the travis action for the deploy stage, all it does is build as far as I can tell.

I recently took over as the primary maintainer of the octoprint/octoprint official image, and I'm really enjoying the way you guys are doing things, but I'm just looking to connect the dots for that final step.

Are you doing the final publishing of images via auto builds on docker cloud?

Love your work, and appreciate any insight you can give me about the image publish step of your overall workflow!

[SimenB]

What mechanism are you guys using to actually push images to docker hub?

The bot opens a PR to the official images, which ends up pushing to docker hub. E.g. the latest: docker-library/official-images#7697

[LongLiveCHIEF]

Of course! Can't believe I missed that since you guys are an official image it would have to be in docker-library/official-images repo. Thanks for filling in the blank for me!

[LongLiveCHIEF]

have you tried leaving stdin open without attaching it to psuedo-tty? docker run --rm -i node:"$full_tag"?

[nschonni]

@nodejs/docker do you want to land this before v14?

[SimenB]

I see no reason to wait to land this if we think it works - it shouldn't be observable to consumers anyways.

The way it's set up now it'll trigger an upstream PR even if a build fails - is the idea that it'll fail from the PR first anyways, so no broken versions can land on master?

[nschonni]

Yes, but i'll also look at that after this lands. I just didn't want to mix too much together

[SimenB]

Needs to be updated for v14.

Should we keep the travis builds for a while to try GH Actions out, and then remove travis if we're happy? I fully expect we'll be happy with it, but who knows 🙂

[nschonni]

Added v14, and dropped v13

[SimenB]

@nodejs/docker thoughts on this one? I like it, FWIW 🙂

[nschonni]

I think I'll go ahead an land this sometime after the security releases are out and are successfully published next week

[nschonni]

I'll land this tomorrow unless anyone from @nodejs/docker has any objections

[SimenB]

I'm still hugely in favour 👍