iterative
Retrieve exclusion list from environment variable
Suggested solution for #802, along with https://github.com/iterative/terraform-provider-iterative/pull/665
I haven't tested this yet. And I don't think this should be the permanent solution. I am in favor of setting up the CI agents as their own service that the runner monitors so that their parent is systemd and not cml, thus avoiding the env leaks.
⚠️
This should have a blog post for some migration information on how to use the --cloud-permission-set for all three providers as the leaking (in the case of AWS) is slightly displayed as a feature example:
Would be awesome if in the description PR you could explain how this is set or used.
Maybe I would prefer ; as a separator
Would be awesome if in the description PR you could explain how this is set or used.
Maybe I would prefer
;as a separator
it is set in the linked PR for tpi: https://github.com/iterative/terraform-provider-iterative/pull/665
it is set in the linked PR for tpi: iterative/terraform-provider-iterative#665
This PR assumes
:
sorry for only for the first part of your question, how it is set/used
Maybe I would prefer
;as a separator This PR assumes:
I'd rather prefer the ⚔️ emoji as a separator, but there is a clear reason to choose : over ; to separate items: VALUES=ONE;TWO would produce sh: command not found: TWO because ; is used by the shell to separate command lists. Of course, quoting is always an option. 🤷🏼♂️
Reply to https://github.com/iterative/cml/pull/1164#issuecomment-1244635335
I don't think this should be the permanent solution
Neither do I 👍🏼
I am in favor of setting up the CI agents as their own service that the runner monitors so that their parent is systemd and not cml, thus avoiding the env leaks.
Sounds worth considering, although would effectively separate cml runner --cloud from cml runner 👍🏼
This should have a blog post for some migration information on how to use the --cloud-permission-set for all three providers as the leaking (in the case of AWS) is slightly displayed as a feature
Looks like the HCL snippet at https://github.com/iterative/terraform-provider-iterative/issues/602#issue-1259912548 could be a good starting point
as the leaking (in the case of AWS) is slightly displayed as a feature example:
That's poor wording on the cml.dev/doc pages. The intention was to say "users only need to go through the nightmare of obtaining cloud auth tokens once for both cloud storage AND provisioning." It was NOT meant to imply "we inject your provisioning-auth-tokens into the provisioned machine just in case you want to use them for something else."
