18f-scaffolding
18f-scaffolding copied to clipboard
18F
does deploy script require all env vars to be defined via user-provided services?
I would like to use the 18f-cli deploy script for Micropurchase similar to how it is used at https://github.com/18F/acqstackdb/blob/develop/.travis.yml#L26-L33
but my current setup relies on some env vars that are defined in manifest.yml and manifest-staging.yml in my project. is there a way of using those? It doesn't look like acqstackdb has any manifest files within version control....
You can set the script to use a specific manifest.yml (rather than building it from the running instance before pushing) by using the --manifest flag. However, with that option the script won't pull in variables from either user-provided services or cf set-env; it'll use the manifest exactly as is.
Can I ask why you prefer setting the variables in the manifest over setting them on Cloud Foundry? The script theoretically could be updated to pull variables into that manifest, but there are a couple reasons why I don't like that idea.
EDIT: I was thinking about my reasoning for this (largely about avoiding putting tokens/secrets in a version-controlled file), and realized that the script could create a temporary copy of the manifest and work on that instead. All else being equal, I still think there's a benefit to create-app-manifest, but this should work.
I think https://github.com/18F/18f-cli/commit/d3afeb60f9f8f495dee529fb4f13d6a989711279 should handle it, but I'm going to review it again before making it available.
@stvnrlly Right now for Micropurchase we use the manifest files to set non-sensitive env vars. Eg: https://github.com/18F/micropurchase/blob/develop/manifest.yml
I find env vars easier to read in this format than when they are accessed via user-provided services. But I can use those for all env vars, if necessary. Which it sounds like it is!
It's definitely my personal preference to store as much as possible in the CF space itself, but I don't think that it's a policy.
To be honest, though, I'm not sure that 18f deploy is quite ready to handle env vars in a UPS the way that you want to use them. I think that Micropurchase is set up to use the long version of the env vars, where the UPS name is combined with the key to create the env var key, but for something like RAILS_ENV you'll always want the short version without the UPS name. You can work around that by using cf set-env, which will be pulled in when the new manifest is created but can also be accidentally lost if somebody does a "normal" zero-downtime deploy (not likely, especially if you remove the manifests from the repo, but still possible).
@stvnrlly if we had a UPS named rails with a key of env wouldn't that get us RAILS_ENV ?
Ok created a PR for this update here: https://github.com/18F/micropurchase/pull/992
Question: if someone wants to deploy manually, is there a recommended way to enable that? Couldn't find anything related to manual deploys in the acqstackdb repo...
another question about this setup: is it problematic that we are no longer specifying a ruby buildpack?
Yep, you can deploy manually with the simplified version of the same command: 18f deploy micropurchase-staging should work.
And as for buildpacks: without a manifest, the presence of Gemfile would cause CF to use the ruby buildpack. But 18f deploy will build a manifest from the currently-running instance and build on that to try to maintain consistency between your running app and the newly-pushed app replacing it. You can see what that manifest looks like by running cf create-app-manifest micropurchase-staging. You'll see that it pulls in the current buildpack, in this case the multi buildpack.
It doesn't look like there's a command to change that setting for a running instance (which makes sense, I guess). It might make sense to add the ability to pass things like that to the push command, but in the meantime I think I can fix this by messing with the script a bit locally.