-
Notifications
You must be signed in to change notification settings - Fork 43
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
feat: docker #759
feat: docker #759
Conversation
apparently semantic-release likes this better I don't know
technically a chore but making it a feat to see what semantic-release does with it
# [8.6.0-next.2](v8.6.0-next.1...v8.6.0-next.2) (2023-02-10) ### Features * add git + changelog plugins ([85e4bfd](85e4bfd)) [skip ci]
This reverts commit 4c34207.
hopefully this will put the extra tag on the correct commit?
This reverts commit 05300e7.
This reverts commit edaf715.
Dockerfile
Outdated
@@ -0,0 +1,7 @@ | |||
FROM node:16 | |||
|
|||
COPY . /rdme-docker |
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.
Not sure what the best practices are regarding directory stuff like this... feedback appreciated 😭
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.
It varies a lot AFAIK. I've seen /app
before sometimes, that may be what we use in our main app. You could use /rdme
if you want.
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.
It takes substantially longer to install/build than the composite action approach in its current form because it's rebuilding the container with every workflow run
So will this actually be faster when we start using the registry? We should probably get that working e2e before committing to this approach just to make sure the benefits actually outweigh it here? It's not like this is a complicated project, and npm install can't take that long. Where as node:16
which is the base image we're using here is a not-exactly-lean 340MB:
$ docker pull node:16
$ docker images --filter=reference="node:16"
REPOSITORY TAG IMAGE ID CREATED SIZE
node 16 ce3d204ff857 2 minutes ago 340MB
I dont know either way which approach is better, but would be interested to prove it out more to ensure benefits. We could also investigate using one of the leaner docker images like 16-alpine, which is a slightly more palatable 42.3MB:
$ docker images --filter=reference="node:16-alpine"
REPOSITORY TAG IMAGE ID CREATED SIZE
node 16-alpine 1621ddffc775 39 seconds ago 42.3MB
Yep, that's the point of the prerelease pipeline in #746 🙃 and didn't know about |
Sorry I didnt know about that! Hoping it all speeds up nicely 🚀 |
🧰 Changes
This is a tiny PR to get our GitHub Action using Docker instead of a composite action. It takes substantially longer to install/build than the composite action approach in its current form because it's rebuilding the container with every workflow run, but I'll get the container registry publishing going in a separate PR (once this and #746 are in
next
) so we can really speed things up 🚀🧬 QA & Testing
Do our GitHub Actions dry runs continue to work as expected?