Closed cywang117 closed 2 years ago
https://github.com/product-os/flowzone/pull/256 was opened in the Flowzone workflow to support passing BALENA_TOKEN
as a secret. This would allow the secrets: inherit
directive to enable repositories with this secret to be more plug-and-play with deploy-to-balena-action.
Instead, repos which add Flowzone need to set a BALENA_API_KEY
secret which Flowzone translates to BALENA_TOKEN
input for deploy-to-balena-action.
The PR was closed because of https://github.com/product-os/flowzone/pull/256#pullrequestreview-1138032069.
I think given that other examples of an authorization credential being referenced uses the convention of $_TOKEN
, this seems like the standard interface.
Coupling workflows/actions via these unwritten interfaces seems like a slippery slope too. It feels contrary to being composable if we have to change downstream actions.
The cost seems to be...
All repos using deploy-to-balena-action update their workflow OR All repos referencing Flowzone update their workflow
I can see push back on updating Flowzone since Balena will have to go and update all the repos using Flowzone to pass BALENA_TOKEN
. The alternative is we push the work to users of the action to update (not required but they'll get a deprecated message and adds complexity to the action code now).
If workflows using Flowzone have secrets: inherit
, no change is needed from them if we update Flowzone to have if: ${{secrets.BALENA_TOKEN || secrets.BALENA_API_KEY}}
sorta logic. (I'm not sure I like this but just saying there's some flexibility with secrets: inherit for reusable workflows)
@20k-ultra You may be right that users of the action that aren't using Flowzone would have a worse experience. I'll close the PR for now, since it looks like the issue that triggered all of this in the first place was fixed by setting a different secret in the org where it occurred.
I opened https://github.com/product-os/flowzone/issues/264 to discuss this more.
Flowzone's secrets uses BALENA_API_KEY instead of BALENA_TOKEN; we could allow both for flexibility.