Add --profile and --region flags

[tj]

Might as well, FWIW you can also use AWS_PROFILE to swap that out if you're not using .profile in up.json.

[kaihendry]

AH! Now I know what you mean by .profile, I thought you were referring to a filename ~/.profile! You mean a JSON path!

jq .profile up.json

I want to keep "foo-dev" in my up.json, since that's what account is uses in development. But come deployment, I want to be able to override it:

deploy:
 # demo
 - provider: script
   script: AWS_PROFILE=foo-demo AWS_ACCESS_KEY_ID=$AWS_123401051872_ID AWS_SECRET_ACCESS_KEY=$AWS_123401051872_SECRET up
   skip_cleanup: true
   on:
      branch: master
 # production
 - provider: script
   script: AWS_PROFILE=foo-prod AWS_ACCESS_KEY_ID=$AWS_123458993663_ID AWS_SECRET_ACCESS_KEY=$AWS_123458993663_SECRET up
   skip_cleanup: true
   on:
      branch: master

Maybe this works already, need to try it. Otherwise, yeah, I need --profile I guess?

[tj]

It should work actually, but it's a bug hahaha... up.json should technically take precedence over the AWS_PROFILE env var, but I believe it's the opposite right now. I think --profile would do the trick.

For now if you want to remove profile from up.json, you could use https://direnv.net/ and create ./.envrc in that project's root directory with:

export AWS_PROFILE=foo-dev

It's a nice tool for project-specific env vars, they get loaded as soon as you cd into that dir

[kaihendry]

Wouldn't a lot of these issues be moot if we could simply choose an alternative up.json?

• up.prod.json
• up.dev.json
• up.demo.json

[tj]

Possibly, I'm not a huge fan of that style personally since we already have stage-level overrides in up.json, profile could maybe be overridden per-stage there too.

It wouldn't help the CI case much since you'd have to get a ~/.aws/credentials file going, it's a bit easier to use the AWS_* env vars, profile is ignored in that scenario since it already has the credentials.

[kaihendry]

Sorry, I think there is some confusion here since I'm cool with the {staging,production} overrides in each account, but I also need account level up.json with profiles AND with different domain options and possibly changes to error_pages et al. (I think)

That's why I am doing this horrible https://github.com/unee-t/processInvitations/commit/4b80273d6c065b8074bd444396416ab6c48e0cec to set the domains correctly per account.

Little bit confusing, though Apex has this env switch that I've found useful for toggling different configurations. So I have a deploy script like:

apex --env stage deploy
apex --env prod deploy

Which IIUC picked up:

• project.stage.json
• project.prod.json

Respectively for configuring each deployment.

[stephenmathieson]

Don't know how much it matters, but won't adding flags like this tie up to AWS even more? For example, if Google Could support is added, what will these flags do?

[tj]

yeah potentially, but honestly there's not enough money in this to start adding other providers anyway :D