Closed mickmcgrath13 closed 1 year ago
What about a checked in file or a github secret? If the list get's too long the user might prefer to handle this in a file instead
checked in file could work well, I think. Don't think github secrets is the way to go because these packs are not sensitive and would value form clearly visible config
If we want to control it via file, then just allowing to specify the user's Ansible vars would work perfectly and not only for packs, but all the StackStorm deployment configurations, see (https://github.com/bitovi/github-actions-deploy-stackstorm/issues/7#issuecomment-1370101010).
If we want to still control it via GH actions config, then it's more useful to have them as a list instead of comma-separated string: https://github.com/bitovi/github-actions-deploy-stackstorm/blob/8b28995ef56abd428d5cbba247fbca9e1fb246d9/action.yaml#L59-L61
Looks like list / multiline support if coming as per https://github.com/actions/toolkit/issues/184 Though it's been in dev for roughly a year+ at this point so don't hold your breath for its conclusion
Thanks for the research! That's helpful, didn't know it's not natively supported by the GH Actions themselves.
So we leave it as is (it works) until proper support from Github.
So I currently have two solutions (as PRs) for this;
example GHA input
dev/packs.txt
packs.txt
- st2=v1.0.7
- circle_ci=v0.5.3
- packagecloud=v1.0.1
- aws=v1.2.1
- etc
could this just be handled with the ansible variables st2.yaml? https://github.com/bitovi/github-actions-deploy-stackstorm/pull/32
We can close and forget about this issue when https://github.com/bitovi/github-actions-deploy-stackstorm/pull/32#pullrequestreview-1243007204 is merged and so packs install list could be overriden by the custom user-specified ansible vars file. No need for another abstraction or dedicated file.
This way we allow 2 user flows: 1) simplified via GH Actions config (1st day - simple deployment)
The 1st should be easy as possible and in this context the string of comma-separated packs is not just fine, but really fits perfectly. The 2nd approach allows more detailed configuration.
We'll encourage users to begin with 1st approach to get started and in case of more detailed configuration, continue with 2nd approach (including defaults overrides) for StackStorm deployment via Ansible vars.
Hope that story would make sense.
Current
st2_packs
value is a comma separated string which might result in a long, hard to parse string like:Ideally, we could provide a list instead like: