A new action to create constructor-based installers

[marcoesters]

Both Anaconda and conda-forge use constructor to create our respective installers such as Miniconda and Miniforge. The process to build these installers, however, still uses different code bases. For this reason, members of Anaconda and conda-forge created an initiative some time ago to align more on how we build installers.

While this effort has been dormant for a while, I recently created a composite action to build constructor-based installers to finally implement this initiative: conda-incubator/installer#63.

I welcome your comments and feedback. I think that with a common open-source workflow, we could share the maintenance load and help each other improve our build workflows.

The action returns a directory with all constructor-generated output, which includes the installer but also other output such as hash files (if requested). That directory can then be fed into upload actions, tests, etc. It currently supports:

• Using GitHub Actions expressions to set environment variables, dependencies, etc., for the build environment.
• Using any standalone binary such as micromamba.
• Using Docker as the build engine. Since environment variables are set in the environment.yaml and can use GitHub expressions, no passing of variables via -e is necessary.
• It works on all three major platforms (Linux, macOS, and Windows).

The action is still fairly simple, but should be able to build Miniforge installers as is.

If there is interest in using this action once merged, I am happy to create the PR here to migrate to it. If not, feel free to close the issue.

[hmaarrfk]

Sorry I didn't see the note to be part of the team. I'm definitely interested in helping. I use the ideas from Miniforge in my own work so the goals of the team definitely align with me.

Thanks for taking on the task to create a github action. Those are definitely new to me and I don't take advantage of them enough.

I do find that they do something like "vendor lock" which we somewhat aggressively stay away from at conda-forge. Is it possibile to use bash scripts in github action? where the majority of the "logic" is in the shell file, and the "configuration" is done through the github actions?

I personally prefer that since it provides a straightforward path to easy local execution.

[marcoesters]

Is it possibile to use bash scripts in github action? where the majority of the "logic" is in the shell file, and the "configuration" is done through the github actions?

Yes, you can. You could replace the parts that create the environment with a call to a bash script. I'm not 100% certain if there are any Windows gotchas though.

There is a trade-off with container images though (they complicate a lot of parts of this action). There a lot of variables that are based on inputs and step outputs, which are rendered into the script that GitHub Actions generates. Refactoring this into a callable script means that the variables I define in the script also have to be added env object of that step and the docker run command via the -e input parameter. I find that kind of manual synchronizing error-prone and a gateway to sneaky bugs, so I shied away from that.

I personally prefer that since it provides a straightforward path to easy local execution.

Local builds were not my primary concern, but I definitely see the convenience of it (I just run constructor locally because I set up the environment once and then don't need to run all those set up steps again).

I can try and think about a way to address both concerns. As the action grows, there are maintenance trade-offs to consider: more inputs (and thus variables) will be created and the build script will grow.