samba: Add autobuild.yml files for dep resolution #2279
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This is the initial attempt at showing how to use the power of autobuild for getting the Solus monorepo under control re. dependency cycles. It is based on this gist.
The purely additive nature of the autobuild.yml configuration files added with this commit, should make it trivial to modify and extend the ignored set of dependencies for a package as our cycle-discovery journey advances.
To gain an appreciation of just how useful this tool might become for us, consider the following:
The above ^ shows how autobuild might resolve a build + rebuild order for when someone is doing a samba stack upgrade and pushing it to a single builder; like, say, the local packager's machine or the current Solus build infrastructure, which is limited to one builder.
Note that autobuild also already supports committing+pushing to the Solus builder, which implies that it can replace the current
build_pr.sh
script in short order, if the the appetite to do so is present within Solus as an organisation.But that's not all!
In fact,
autobuild
also supports generating a "tiered" builder order (notice the-t
argument), which those of you packaging KDE might already be familiar with:Tiers (called "Precedence Constraint Groups" in graph theory literature) effectively show which packages can be built in parallel since they do not interdepend on each other.
With the -q argument like above, this build order could potentially drive a set of builders (like summit does in the Serpent infra currently):
I hope this serves to show how useful autobuild can potentially become to Serpent and Solus in terms of automating the discovery of build and rebuild orders.
This commit is mostly intended as a way to showcase what an autobuild-driven packaging process might look like for Solus and Serpent, and as a starting point for the discussion of how to tag "Auxiliary Dependencies" in a way that's compatible with both the Solus and Serpent monorepos and tooling.
See also: #2175 and #2176
autobuild.yaml format design notes here: GZGavinZhao/autobuild#16
Massive props to @GZGavinZhao for his interest in studying the necessary graph theory at my suggestion, and also for his being ready, able, and willing to design and build this tool, and for his willingness to take on board constructive feedback re. the documentation and UX necessary to productise this solution for a wider audience of Solus staff and community packagers.