I think we can trade out env vars for just (multiline) inputs. We can keep the current behavior around so there's no breaking change.
Why
Env vars have always felt kind of amorphous and half-formed to me. They contain very little information about themselves. I also don't think they were intended for this. They feel like the wrong fit for the purpose.
This method might let people tell us which variables of theirs are sensitive and which are just variables.
This would reduce the number of Steps people have to learn. It would let us put sensitive info in Story Tables and let everyone use the regular "set" Step for sensitive info too.
It would let us log and take pictures of public variables created with secrets, giving our users more information about failing tests.
It might unify the way ALKiln takes in values by keeping everything under inputs.
It might simplify and unify the explaining we have to do. People may still need to make env vars to make safer workflows, though since they're making a workflow instead of an action, I wonder if that might just be for inputs. Even if they do end up needing to do that, we can more easily point to documentation without needing elaborate explanations because they'd be used as intended.
How
We'd parse strings for 2 different inputs:
with:
ALKILN_SENSITIVE_TEST_VARIABLES: |
foo: ${{ secrets.FOO }}
ALKILN_PUBLIC_TEST_VARIABLES: |
bar: bar
Proposal
I think we can trade out env vars for just (multiline) inputs. We can keep the current behavior around so there's no breaking change.
Why
Env vars have always felt kind of amorphous and half-formed to me. They contain very little information about themselves. I also don't think they were intended for this. They feel like the wrong fit for the purpose.
How
We'd parse strings for 2 different inputs:
Are there downsides to this?