Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Different container registries in dev and prod

See original GitHub issue

In development, I’d like to use a local container registry for the location of images (see https://github.com/datawire/forge/issues/145), but in CI deployments, I need to use GCR. Currently, forge.yaml appears to support specification of only one registry.

This could be supported in a few ways:

a --config / -c flag to forge build|deploy to read a specific forge.yaml, and then I define 2 different ones.
Make forge.yaml profile-aware.
Make forge setup unattendable, so I can run it as a pre-step with different parameters in CI and in dev before forge deploy.

Issue Analytics

State:
Created 6 years ago
Comments:5 (3 by maintainers)

Top GitHub Comments

1reaction

rhscommented, Feb 22, 2018

I’ve released forge 0.4.3 with a forge.yaml that supports profiles. I believe that should complete all the items discussed in this issue.

As an aside, I’m intrigued by your comments around the VOLUME directive. We have a couple of vaguely similar sounding schemes geared towards enabling fast incremental container builds and/or live reloading of stuff running in a container. I’m kinda curious about the details of what you ended up with. I’d really like to provide a more general solution to this class of problem. Would it be possible for you to share a working project skeleton?

1reaction

rhscommented, Feb 16, 2018

I just released forge 0.4.2 which includes part of what is discussed here. The docker user and password are now optional, so it should be possible to create completely secret free forge.yaml files and check them into source control.

I hope to finish up this and #145 early next week.