Integrate the snabb-lwaftr-release jobset into the main snabb jobset

[teknico]

As suggested by @domenkozar a while ago, this moves the currently separate snabb-lwaftr-release jobset into the main snabb jobset.

The latter will need another input with name lwaftrSrc and value https://github.com/igalia/snabb.git lwaftr.

[lukego]

@teknico @domenkozar Just now we don't really have an upstream maintenance procedure for snabblab-nixos. Simplest is that we each just push code to master when we are confident that it works e.g. by running a build using our branch of snabblab-nixos and checking that it works.

Better solution might be to have a next branch that is tested with dedicated jobsets and to use that for staging i.e. push to next, wait and see that the evaluations look right, then merge next to master. However we don't really have that tradition up and running now and since the rate of churn is low we might be able to get away without so much ceremony.

So just to get the ball rolling I created a "maintainers/developers" Github group and added the people who came immediately to mind: me, @domenkozar, @teknico, @dpino. Hopefully we can work out a good workflow amongst ourselves?

[dpino]

I agree with the proposal. If making any change at snabblab-nixos code, I expect to be mostly on the settings of our bencmarking machine (snabb-2 at this moment) and likely that will happen once in a while. Pushing directly to master sgtm.

OTOH, If someone is uncertain of a change (maybe a change breaks something in another machine sort of thing) can push a pull-request to master and ask for a review before merging.

[lukego]

One more possibility for the future is that we can spin out the test case definitions to their own repositories that are separate from the lab server build definitions. This way we limit the scope of accidents. But for the moment maybe we are okay with just making sure we have tested everything at least once before we push it to master.

[domenkozar]

Pushing to master sounds good to me. Since it's all built by Hydra we can pinpoint any breakages and revert them.

[lukego]

One more important issue is that currently we have a lot of large jobsets referencing the master branch. So pushing even a trivial typo fix can fire off tens of thousands of tests in the Hydra queue.

Could be a solution to make those tests reference another more stable branch instead so that we can comfortably update master and still control when the changes are rolled out to the jobsets for specific applications.

(Just this particular problems I can probably solve by creating an nfv branch that pulls master when it makes sense.)

I can't wait for Hydra declarative jobsets to be working... no fun maintaining all the jobsets by clickety-clickery :)

[domenkozar]

Ideally we'd have a tool that predicts number of changed tests before merging.

If we push to master this might become a problem, since one can spawn literally thousands of jobs.

Somewhere there is a balance between a quick workflow and not breaking too much of our CI.

I'm fine either way that works for you and Igalia :)

[dpino]

Could be a solution to make those tests reference another more stable branch instead so that we can comfortably update master and still control when the changes are rolled out to the jobsets for specific applications.

This solution sounds good to me. Push directly to master, make Hydra point to a stale branch and update this branches with the changes from master in a more controlled way.