Versioned layer name #10
Conversation
|
Oh nice! This is rather clever and done in such a way that any env we needed from the container can be used. Not the approach I would have taken which is JUST FINE. I would have likely done an explicit file called |
|
Thanks! I was worried it was in breach of YAGNI, but I always feel like backtick cats are a little hacker than just sourcing a file. Loved hearing a rubyist on the Jeremy Daly podcast a few months ago - just realised that was you. 👍 |
|
Whoa! Thanks. BTW, I did change this to |
|
Ah nice. I’ll look into that; I do die a little inside when I need to wrestle with pyenv and nvm (serverless framework) when I’m writing ruby. |
I think I understand your suggestion in your comment on issue #9 - is that to ensure that if the scripts are run without an explicit VIPS_VERSION being set, or if the Dockerfile is run without the build.sh script, then the deploy.sh script will still have access to the version info? And, the version used in the Dockerfile is canonical?
The Dockerfile in this PR creates a file named
.envwhich is copied (with the zip file) to the host and is then sourced by the deploy.sh script. I guess, in future, additional build variables can also be stored in there if the user needs access to those after the library is built.Layers cannot contain a
.so I'm just droppping these with${VIPS_VERSION//./}I've tested deployments with:
1.
bin/deploy- which builds v8.7.4 (the default in bin/build) and publishes asrubyvips8742.
VIPS_VERSION=8.9.2 bin/deploywhich builds v8.9.2 and publishes asrubyvips8923.
VIPS_VERSION=8.9.0-rc4 bin/deploy(just to check the edge case version name) which builds v8.9.0-rc4 and publishes asrubyvips890-rc4