Autobuild: Avoid building release only builds on PR

[ann0see]

Short description of changes

This PR adds some logic to avoid building ARM, JACK etc. builds except on releases. This is still in draft stage.

CHANGELOG: Internal: Avoid building release only builds on every Pull Request. This is done to save resources. Context: Fixes an issue?

https://github.com/jamulussoftware/jamulus/discussions/2282#discussioncomment-2046262

Does this change need documentation? What needs to be documented and how?

No.

Status of this Pull Request

Still in Draft. Needs to be tested. Maybe the approach doesn't work at all.

What is missing until this pull request can be merged?

Testing, review.

Checklist

• [ ] I've verified that this Pull Request follows the general code principles
• [ ] I tested my code and it does what I want
• [ ] My code follows the style guide
• [ ] I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• [ ] I've filled all the content above

[ann0see]

Actually, I think needs some engineering in our prepare release step: https://stackoverflow.com/questions/65384420/how-to-make-a-github-action-matrix-element-conditional

[pljones]

Can this please be updated to make it clearer what the goal is.

Currently it says "to save resources". What resources? Disk? Time? What is the problem being fixed?

Then it should also state here how that goal will be achieved. That is, what the selection criteria are for determining which steps in the build process to include/exclude.

[ann0see]

Currently it says "to save resources". What resources? Disk? Time? What is the problem being fixed?

Build time, space (but not much). Also it allows to have more useful macOS runners. If there are multiple macOS runners working, the pipeline gets full quickly (at least we had the problem that macOS builders didn’t start since other PRs blocked them).

One possible approach is in the Link above. I‘ll update the PR.

[ann0see]

I‘m not sure where/if an issue exists, but I know @hoffie and me discussed in some of his autobuild related PRs/Discussions

[ann0see]

Ah. Found the discussion: https://github.com/jamulussoftware/jamulus/discussions/2282#discussioncomment-2046262

[pljones]

OK, it still needs breaking down into something more specific.

• For each trigger of an action
  • and for each job within an action
    • and for each run within a job we should know what the costs of that action are (time, cpu, disk) and what the benefits of running them are.

With that information, we can decide which jobs are the most costly and whether they are worth the benefit, based on the trigger.

---

However...

Any build against master (either a PR or merge) should be able to ("wouldn't it be nice if...") the output of the last merge to master as its starting workspace (and yes, that would mean keeping state per build target). Behaviour could then be based on

• what make would say is dirty
• if it's not a merge and make wouldn't do anything, then don't run the packaging step either

Those could be done very quickly for each target to determine what would be affected. It might be better to base what to actually do on that.

[ann0see]

For the both ARM builds the benefits are low: Debian ARM is very similar to debian amd64, macOS ARM is similar to macOS intel. So the benefit is just convenience of being able to run Linux arm builds on Raspberry Pi on each PR.

macOS Intel builds work on ARM and Intel macs, so the benefit of the arm build is low on PRs.

Cost is high especially for macOS arm since it uses another macOS runner which is not available for other builds. Linux is not that critical and a bit faster.

[ann0see]

So you'd recommend to sync the .o files during runs?

[pljones]

So you'd recommend to sync the .o files during runs?

For each build target, yeah, if that were possible. Timestamping might be an issue - make has to believe the make target is newer than what it's looking as a source for that target.

We'd also need to make sure we were only keeping one set of files for each target - and being very, very certain about that - to avoid storage accruing... It might also not be a saving: it could take longer to save and then restore (persistent storage, possibly over a congested network, to container storage and then back) each time than rebuild everything (container storage only).

The extra complexity involved and the potentially lack of benefit may simply make it not worth worrying about.

[ann0see]

Hmm. I mean we could do something similar to the caching approach for the dependencies. I agree that this would probably hugely speed up the build

[pljones]

Ah yes, I'd forgotten about that. If it's possible, and straightforward, it might be worth a go.

[hoffie]

I don't think we should invest into sharing object files between PR runs:

• Header file changes often trigger rebuilds.
• Sometimes (e.g. everything build-related) explicit cleanups are required.
• We can't share object files between platforms or architectures.
• We can't share object files between different build types (headless vs. normal) due to #ifdefs.

I think the benefit is low, the implementation complexity is high and I'm not convinced that one of the many edge cases does not lead to so many extra CI runs that there is no net benefit anymore.

As an alternative to this PR regarding the default build matrix selection, I'm still planning to submit my already prepared, but not finally tested logic changes as hinted in https://github.com/jamulussoftware/jamulus/pull/2534#issuecomment-1092263931.

[hoffie]

@ann0see With #2789 merged, this PR could be closed I guess?

[ann0see]

Yes.