ci/use local dockerfile #2
Conversation
|
I opted to simply build, push and test in every case, unless there is a specific text on the commit. Having both jobs in one workflow requires a more complex hack to check the files that have changed, and I'm having Github Action hack-fatigue |
|
I figured out how to only do the Docker build step if few files ( |
| @@ -0,0 +1,24 @@ | |||
| FROM hashicorp/terraform:0.12.29 | |||
There was a problem hiding this comment.
Looks like this image inherits from alpine linux, just be aware that alpine uses a different libc (musl) than any other linux operating system (except maybe void? and embedded linux solutions). There are some significant differences in the way the networking system calls work in musl vs glibc (the defacto standard). It shoudn't matter too much here, but I'm suspicious of alpine and musl
| FROM hashicorp/terraform:0.12.29 | ||
|
|
||
| ENV BUILD_PACKAGES bash curl-dev curl ruby-dev build-base python3 | ||
| ENV RUBY_PACKAGES ruby-full |
There was a problem hiding this comment.
These are creating cache layers for each ENV call. I'd inline these into the RUN call below that way the packages and the installation appear in a single cache layer
| COPY Gemfile* ./ | ||
| RUN gem install bundler | ||
| RUN bundle config set system 'true' | ||
| RUN bundle install |
There was a problem hiding this comment.
You could def concat these three RUN directives with &&. I think that'd be better for the docker cache long term, though it doesn't super matter for an image this big
| RUN bundle install | ||
|
|
||
|
|
||
| ENTRYPOINT ["/bin/bash"] |
There was a problem hiding this comment.
Was this set to terraform in the parent container?
Use local Dockerfile instead of generic since the Gemfile is specifying per project