You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My usecase is that I want to execute this via amber exec. But at runtime, I want to change the environment variable appropriately before executing. In the above case, I want to change the environment variable to GH_TOKEN on the appropriate environment before executing.
That looks totally reasonable, sounds great. Only other thought: should we introduce some method to have different potential values for each environment variable? The only term I can think of is introducing environments, which is a confusing term. But what I mean is having something like:
GH_TOKEN_DEV:
dev: DEADBEEF1staging: DEADBEEF2
And then:
amber exec --environment dev -- gh release download
I'd want to use a different term than environment if we can think of one. I'm not sure if I like this more or less than your proposal TBH, just brainstorming.
Interesting idea and I think it's nice. I have to think about this a bit more to see how it fits with the other workflow, let me get back to you on this.
I'd want to use a different term than environment if we can think of one.
I recently had this usecase where I wanted to store multiple similar keys but for test and staging environment:
My usecase is that I want to execute this via
amber exec
. But at runtime, I want to change the environment variable appropriately before executing. In the above case, I want to change the environment variable toGH_TOKEN
on the appropriate environment before executing.I was thinking something like this:
Any objections to have this feature ? I can volunteer to implement the same if there are no objections.
The text was updated successfully, but these errors were encountered: