Instead of build_args you should use args (example below) but keep in mind the build directive is an undocumented and experimental feature and could be removed if we cannot solve some remaining design challenges. We also lack a subprocess to prune old build layers, which means your servers could fill up when using this feature. The recommend way to build and publish an image is the docker plugin which you can find here.
PS sorry if my post about this feature comes off as negative, I just wanted to make sure I was up front about its current status. I certainly hope we can work through some of the known issues and fully support this feature and syntax going forward
I appreciate the help! Do you know if there is a generic way for a drone.yml configuration to use a secret anywhere else in the yml?
My problem is this: I have a ruby project that uses a gem pulled from github, so I need to pass in a secret key as a build_arg to download it. I’ve checked the documentation for ECR plugin (we don’t use Dockerhub), but don’t see an explicit parameter for something like this, so my next thought is I would just use their build_args property but pass in a secret that I retrieve from Drone. Not sure if this is doable or if I’ll need to create my own plugin to do something like this.
I have provided a couple of options below. Note that this is not the full syntax for using the ecr plugins, but should hopefully give you enough information to get started.
Option 1
One option is to source the build_args value from a secret. The build_args are passed to the plugin as a comma-separated list which you can emulate.
Or alternatively the plugin allows you to source build_args from the environment. So in this case, you source environment variables from secrets, and pass those environment variables as build args.
Apologies for all the questions. That solves my issue of building and pushing the image to ECR (hooray) but ideally I would test it before I pushed it. Given that the build directive is experimental (meaning I wouldn’t want to rely on it), what’s the next best alternative to building an image from a Dockerfile and using that on subsequent steps, while still being allowed to pass in the secret as a build argument?
I’ve tried not building an image and just putting the few lines from my Dockerfile as commands but
This is not really acceptable since what’s tested could differ from what the Dockerfile creates, and
Accessing these secrets are difficult; I haven’t figured out all the valid ways they can be used! Something like this does not work (are they only usable as “input parameters” and never as “inline values”?):