feat: extend molior capabilities to support environment variables in buildtime

[BenediktBertsch]

Background

I need in my project to be able to pull from internal artifact repositories with my custom login credentials. This is needed because projects have a limited space of git-lfs / repository space (10GB) which we reach after 10-15 releases if we create everytime a cache file that contains all our needed dependencies for the build time.

Current flow looks like this:

• New release is requested
• We create a new artifact (Conan)
• The version of our conan artifact (e.g. test/1.0.0)
  • update referenced in our pre-release script we generate a cache file
  • add it as a git-lfs object to our repository
  • push it
• Repeat until we hit the limit (now how I fixed it for now, which is not feasible long-term...)
  • Use https://github.com/rtyley/bfg-repo-cleaner to edit the git history of ALL past releases (retry functionality and idempotence is broken with that)

Wanted flow would look something like this:

• New release is requested
• We create a new artifact (Conan)
• (One time) update molior-trigger-build call with for example -e [--env] "key"="value", which then can be also used within CI/CD system e.g. GitLab like this molior-trigger-build -e "CONAN_ARTIFACTORY_PASSWORD"="${CONAN_ARTIFACTORY_PASSWORD}"
• The version of our conan artifact (e.g. test/1.0.0)
  • update referenced in our rules file that points directly to our Conan repository
  • push it

Idea

I've thought a bit how this could be handled e.g. environment variables are saved encrypted with AES-256 at rest, will be removed after a TTL of 24 hrs (would be great for retries of builds, if needed). On build request it should automatically send the runner these additional environment variables. Important to note is also that these credentials shouldn't be exposed via Logs, which means these also have to be filtered / redacted somewhat.

[neolynx]

molior 1.4 was using schroot / sbuild, which made it pretty hard (on purpose) to inject information into a package build.

in 1.5, we have our own docker based builds, so we can plan in such features.