Use env vars rather than step's context

[mgoerens]

This change is meant to: a) Make it easier to spot which inputs needs to be passed to a step. b) Improve step's portability.

This is a first iteration of this logic, focusing on the recent changes to chart-repo-manager and update-index.

[komish]

@mgoerens I'm actually going to close this for now.

In the PoC I'm working on, I noticed that using environment variables in run steps leaves it unresolved within the code. E.g.

run: echo "${FOO}"

...would look exactly like that, at execution, in logs. It's not hard to resolve (environment variables are visible in all action run logs), but it's still an extra step. If we use the ${{ ... }} syntax, the log would have the resolved value.

E.g.

run: command --flag=${{ steps.stepname.outputs.myvalue }}

... would resolve to

run: command --flag=thevalue

That reads a little bit easier.

The original goal was to be able to just "copy paste" the script definition in our run blocks into a bash, python, javascript, etc. script - and be able to run it. That's what I meant by "more portable". I think at this moment, though, I'd rather see it resolved instead of having to look at an extra place in the log.

Feel free to re-open this, but given that I asked for this initially, I'll mark it closed now. Thanks again for you work.