fix: add variable for password fields in jenkins runs / accept stack argument

[qdzlug]

Proposed changes

Fixes a typo in the jenkinsfile, along with ensuring that passwords are all handled via a jenkins variable.

Adds in logic to accept the pulumi stack on the cli and manage the environment file.

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have written my commit messages in the Conventional Commits format.
• I have read the CONTRIBUTING doc
• I have added tests (when possible) that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto master
• I will ensure my PR is targeting the master branch and pulling from my branch from my own fork

[dekobon]

Does this change completely remove the environment file or just add the option for a --stack argument?

[qdzlug]

This change leaves the environment file intact because it occurred to me that we may want to use the file in the future to pass through environment variables to the program (one thing that comes to mind is docker and the various docker replacements).

The logic honors the stack name in the environment if it matches the stack name passed through, updates the environment file with the stackname if the environment file doesn't exist, and uses the value given as a variable in case they differ from each other.

[dekobon]

Please break apart the commits for content changes to markdown from formatting changes. If other changes are mixing in with the commit for reformatting, it can really difficult to distinguish it when logging through the git history.

[4141done]

Left a few comments that but not approving since I don't have my head around this nearly enough yet - I'll leave that to @dekobon .

[4141done]

Optional, but if you only need filename consider just passing in filename. If this module exclusively dealt with the env_config object then I could see having functions just take in that object and use fields on it but since this is a general module it would be simpler and less error prone not to force this function to have knowledge of the keys on env_config

[4141done]

Question: if we found a file of the same name but id doesn't contain a stack identifier, would it be simpler to to a write_env instead? That way we always know that the file we wind up with contains the env_config we expect? With append I can see some danger of creating a file that has unexpected stuff.

If there's worry about blowing away some existing config, the file could be backed up before this occurs, or we could prompt the user to let us delete it, or quit the process and deal with it themselves.

I'm lacking a lot of context, but in general my point is that appending to an unknown existing file could create unpredictable edge cases, whereas forcing an explicit write of the incoming config to the file would give us more assurance moving forward that we are working with something known.

[qdzlug]

This is a good point; the case I'm seeing this useful for is one where we decide "we need to pass environment variables into the process through the environment file".

In this case, PULUMI_STACK is just one of the potential variables that would be applied, hence we append. My thought is that if the text gets appended to a file that has garbage in it, the parser will either just ignore it or blow up which should cause the parser to fail.

However, let me test both of the above cases to see if I can get a real answer to those questions.