mirror of
https://github.com/getsolus/packages.git
synced 2025-04-25 12:20:28 +03:00
7e00a498d5
**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. 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: ``` ermo@solbox:~/repos/getsolus/soluspkgs $ autobuild -q query src:packages/ samba ldb tdb talloc tevent talloc tdb cifs-utils notmuch tevent ldb samba acccheck ffmpeg \ python-pysmbc gvfs kio-extras kodi mpd rhythmbox vlc \ gnome-control-center nautilus-share nemo-extensions budgie-control-center ``` 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: ``` ermo@solbox:~/repos/getsolus/soluspkgs $ autobuild query -t src:packages/ samba ldb tdb talloc tevent (.. some output omitted ..) 🗸 Successfully parsed state! 🗸 Found all requested packages in state! 🗸 Successfully built dependency graph! 🗸 Build order: 🗸 Tier 1: talloc tdb 🗸 Tier 2: cifs-utils notmuch tevent 🗸 Tier 3: ldb 🗸 Tier 4: samba 🗸 Tier 5: acccheck ffmpeg python-pysmbc 🗸 Tier 6: gvfs kio-extras kodi mpd rhythmbox vlc 🗸 Tier 7: gnome-control-center nautilus-share nemo-extensions 🗸 Tier 8: budgie-control-center ``` 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): ``` ermo@solbox:~/repos/getsolus/soluspkgs $ autobuild -qt query src:packages/ samba ldb tdb talloc tevent talloc tdb cifs-utils notmuch tevent ldb samba acccheck ffmpeg python-pysmbc gvfs kio-extras kodi mpd rhythmbox vlc budgie-control-center gnome-control-center nautilus-share nemo-extensions ``` 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: https://github.com/GZGavinZhao/autobuild/issues/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. Signed-off-by: Rune Morling <ermo@serpentos.com>
5 lines
139 B
YAML
5 lines
139 B
YAML
# python-pytest is a common cycle-creator, in that it's typically a checkdep,
|
|
# not a true builddep.
|
|
solver:
|
|
ignore:
|
|
- python-pytest
|