New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different container registries in dev and prod #146
Comments
FYI, there actually already is a --config flag and a FORGE_CONFIG environment variable that override the forge.yaml. Personally I'm not sure it's ideal for this case though. My goal is that As another FYI, there is no need to actually run forge setup, you can simply manually create a forge.yaml file for CI, the full format is documented here: https://forge.sh/docs/reference/forge-config I'm also happy to create a non interactive option for forge setup, but I wonder if bypassing it all together might be better? The original intended use case for forge setup was to help users bootstrap through the fussy/brittle registry configuration process. I'm thinking now that gcloud integration is done, with a bit more auth work I might be able to remove all secrets from forge.yaml entirely, in which case a reasonable option for CI might be to simply check in an official CI version of forge.yaml and pass that explicitly to forge when invoked in CI, e.g.: What are your thoughts? I'm mostly thinking out loud here. ;-) |
Yeah, that would be neat. I would love to check in a standard file and have it Do The Right Thing. At the moment, I've managed to work around this by creating a common dev image which include a
I do still need to do some gymnastics to use the right Dockerfile, because they aren't templatisable (#144), but the default can be dev, and then in CI, I just overwrite it with a prod one. I am also thinking out loud :) |
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. |
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? |
Awesome, thanks for all your work on this, can't wait to try it! Happy to help with a reference implementation. Focused on non-build-related things for the next week or so, but will try and put together a simple example soon after that. |
In development, I'd like to use a local container registry for the location of images (see #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:
--config
/-c
flag toforge build|deploy
to read a specificforge.yaml
, and then I define 2 different ones.forge.yaml
profile-aware.forge setup
unattendable, so I can run it as a pre-step with different parameters in CI and in dev beforeforge deploy
.The text was updated successfully, but these errors were encountered: