I'd like for this action to provide an option for installing arbitrary maintenance builds instead of just nightlies.
This would be useful for testing against the current state of a release branch or a specific feature branch and could be helpful for testing particular shards directly.
Another use case would be test-ecosystem where we're testing new compiler versions and features against core parts of the Crystal ecosystem.
The old test harness runs a compiler build in test-ecosystem itself. I'm in the process of restructuring and simplifying this process (https://github.com/crystal-lang/test-ecosystem/pull/45). If we could re-use existing maintenance builds for this, it would cut some extra effort there. Enhancing this action for that purpose would be a great tool for that and it shouldn't be hard.
Currently the install action can fetch nightly build artifacts when the value of the Crystal version is set to nightly. This works by querying for the last successful run of the dist_artifacts job no circle CI (Linux/macOS) or the win.yml workflow on GitHub (Windows), each on master branch.
Enabling support for maintenance builds should not require anything else allowing to modify the branch for these queries. Instead of master, one could chose any branch that runs the maintenance release workflow.
I think the configuration could allow free-form values for the crystal version property. Anything that is not nightly or a version tag would be understood as a branch name.
If we want more explicitness, maybe a prefix like branch: could be a requirement?
I'd like for this action to provide an option for installing arbitrary maintenance builds instead of just nightlies. This would be useful for testing against the current state of a release branch or a specific feature branch and could be helpful for testing particular shards directly. Another use case would be test-ecosystem where we're testing new compiler versions and features against core parts of the Crystal ecosystem. The old test harness runs a compiler build in test-ecosystem itself. I'm in the process of restructuring and simplifying this process (https://github.com/crystal-lang/test-ecosystem/pull/45). If we could re-use existing maintenance builds for this, it would cut some extra effort there. Enhancing this action for that purpose would be a great tool for that and it shouldn't be hard.
Currently the install action can fetch nightly build artifacts when the value of the Crystal version is set to
nightly. This works by querying for the last successful run of thedist_artifactsjob no circle CI (Linux/macOS) or thewin.ymlworkflow on GitHub (Windows), each onmasterbranch. Enabling support for maintenance builds should not require anything else allowing to modify the branch for these queries. Instead ofmaster, one could chose any branch that runs the maintenance release workflow.I think the configuration could allow free-form values for the crystal version property. Anything that is not
nightlyor a version tag would be understood as a branch name. If we want more explicitness, maybe a prefix likebranch:could be a requirement?