Just going to capture the relevant discussion here:
ermo
Ikey, as I've been doing some work on pisi and eopkg, I think I'm realising that there's actual value in having easily accessible (but unofficial) testing artefacts associated with a try-build PR.
i.e. artefacts that people can help test without building the actual recipes.
I think to translate that into moss, you'd sort of need a private overlay repo...?
that you could enable/disable via, say, moss pkg test-pr and then moss does all the heavy lifting in terms of enabling the repo and installing the PRs in a transaction?
With how moss works, this could be super useful in terms of virtiofs-based VM testing?
or even just container / distrobox-like testing?
you know, if the thing built, allow basically everyone to test it prior to landing it?
then when the PR gets merged, moss becomes aware of this and GCs the associated fstx.
(as a normal part of moss sync)
ISTR that you had this sort of branch thing in your mind when talking about cutting releases as well -- this would use the same mechanism, but not be "official" releases.
... now that I think about it, funny how PR could also stand for Pre-Release...
Reilly Brogan
I think I had a whole thing about that last year
About how PRs should be automatically built and the artifacts packaged into a PR-specific index so that the reviewer can add it to their system or a VM and install the artifacts directly
Ikey Doherty
Ya I don't think moss needs any specialist support
ermo
it's likely possible to do it via just
using moss as a simple building block in the workflow
you know, I'm feeling quite good about settling on just and nushell as our "glue".
I think that combo has legs.
Reilly Brogan
I feel like you'd want it integrated into the repo management/package building software
Github action runners are likely not significant, so you'd want the build jobs farmed out to your package builders
And summit/avalanche is already setup to pull in the artifacts and assemble them into a temporary index
So you'd essentially teach summit/avalanche how to integrate with Github PRs instead of creating a concurrent workflow that duplicates a lot of what summit/avalanche are already doing
Just going to capture the relevant discussion here: