Ignore dockerfile

Is there a way to tell garden not to use a Dockerfile? We want our CI to build the containers and expect little to no changes to Dockerfiles from developers. In addition, building the images takes a very long time which we don’t want end users of garden to deal with. Thus far, adding “Dockerfile” to .gardenignore seems like it may work, but feels like thwarting the process.

Hi Dave

Could you add a bit more context. Are you just using the container module type, or are you using it together with the kubernetes or helm module types?

And what are you “doing” when these unwanted builds are triggered? I.e., are you running rests, creating preview envs, etc?

Hi Eysi! Definitely, using the container module type and specifying an image while attempting devMode and hot-reload environments. From what my team and I have seen, this seems to happen both during a garden deploy --hot=(service name) and a garden dev (service name).

We’re also trying to figure out where the best place for the code really is with respect to the garden project.

garden project 
  |_ service name
    |_ git repo
garden project
  |_ service name and git repo (commit garden.yml to repo)

Option 1 successfully ignores the Dockerfile, but would be somewhat challenging to maintain. Option 2 seems to automatically detect and attempt to build the dockerfile.

Thanks, that’s helpful.

You should definitely commit your Garden configuration files. A Garden project always needs to be in a git repository (we rely on a few git commands internally), and a single repository can contain multiple projects.

Now, to skip the build step, you’d need to add an image field to the module that points to the image you want to deploy and set include: [].

This essentially tells Garden that the module doesn’t contain any source code and that it should just deploy the image that’s specified. This FAQ entry gets into a bit more detail on using the image field.

If you want to skip builds during development, but enable builds in CI, you can use the following template syntax:

include: ["${environment.name == 'dev' ? 'undefined' : '*'}"]

So a complete example would look something like this:

kind: Module
name: my-module
type: container
image: my-org/my-image:1.0
include: ["${environment.name == 'dev' ? 'undefined' : '*'}"]
services:
  # ...

Note that you can also you template string for the image version. For example:

image: my-org/my-image:${var.image-version}

Finally, I’d suggest you use the new dev-mode functionality instead of --hot-reload | --hot. It’s quite robust by now and performs a lot better. We’ll be deprecating the previous hot-reload functionality.

And as a side note, we’re looking into ways for enabling dev mode without doing a full rebuild, if the service is already running. That is, if you once ran garden deploy --dev my-service, killed the process, and want to run it again, you should be able to do that without going through a full re-build, even if the source code has changed.

Fantastic! The include (exclude) directive worked like a charm! Thank you so much for your help. Definitely looking into dev mode! Thanks for the recommendation.

1 Like