[Refactor] Remove fastlane context and replace it with environment variables about fastlane

[KrauseFx]

Via @viktorbenei https://github.com/steplib/steplib/issues/68

[joshdholtz]

Hmm, I'm not sure actually. I personally don't think there is anything wrong with either approach. I do like the flexibility that the fastlane context can hold any object 😇

[milch]

How about just shadowing the ENV variables in the lane context? This wouldn't sacrifice the lane context's flexibility and would also remove the need to use both everywhere.

[KrauseFx]

How would that handle complex objects in the fastlane context?

[milch]

The "new" lane context I'm proposing would have the following logic on key lookup:

• Look up the key in the lane context's Hash
• If there was an object returned, return that
• Look up the key in ENV
• Return the result of that

The complex objects would just be stored in the Hash (and could even overwrite values from ENV)

[viktorbenei]

I like what @milch proposes and I'm not that deeply involved with fastlane tools so far, one thing to consider (based on our project @KrauseFx linked) is how much you care about integration with other tools. What we try to solve with the https://github.com/steplib/steplib project is to connect tools no matter what technology it's built with (can be a bash script, ruby, Go, binary, ...). In that case you just can't use a language specific mechanism for sharing parameters / context.

Generally though you probably won't be able to provide a truly "no wrapper required" solution especially if you want to support existing tools, so I think the parameter passing/context just have to support a unified mechanism for which others can write thin wrappers.

For example we have Steps (tools / components) which basically just expose an interface for an existing tool, and the actual Step code is nothing but a really thin wrapper which transforms the inputs from our interface format (we only use environment variables) to the format the actual tool uses (writes a config file or calls the tool with command line parameters).

Sidenote: we handle complex parameters through the filesystem.

I think the format of the context is less important and that the biggest issue is actually handling tool output collisions, when you run the same tool (or two tools which generate into the same output, be it a context, environment or anything else) multiple times and so only the last output will be actually available. It's even more crucial in case a tool/Step creates multiple outputs but might not export all every time it runs.

A minimalistic example is if a tool/step generates both a success state (true or false) and an optional error message output. If the tool first runs and fails it will generate an error message output. If you run it again and it finishes with success then it will probably only generate the state output but not the error message one, so you can end up with a context where the tool's "state" is "success" but an error message will still be available.

Our best solution so far is the one @KrauseFx linked (https://github.com/steplib/steplib/issues/68) but it's not yet tested and it requires a central tool with which other tools communicate. Our plan at the moment is to have a CLI tool installed in a specific path / made available to other tools and so other tools (rather the wrappers around the tools) will communicate exactly with that specific CLI tool to store generated outputs and the CLI tool manages the aliasing of the outputs in a similar way as Docker environment binding works but we're still discussing the pros&cons of this system with our team.

[KrauseFx]

Thanks everyone for the feedback, I'll close this issue for now and won't change how fastlane handles the environment.