First you need to install the docker buildx plugin (the provided script does this)
Then you need to execute runCatalyst.sh with $SPECS set to the path of the specfile you wish to execute, from a directory containing paths.sh generated by build-to-spec.py, this is done by the scripts in example/.
This project was made for the 2021 Google Summer of Code. Throughout these 10 weeks I have learned elements of release building, configuration management, and container systems. The project was created in two main parts. Initially, I got the docker image to build the spec files, but, was having a hard time processing mountpoints for the container. This combined with the frustruation with the verbosity of the existing spec files led to the creation of a new configuration file, in the TOML format.
I compared many different container systems, with an initial reluctance towards Docker, until I saw the docker-buildx scripts for the Gentoo live images. It allowed easy scripting and configuration of the docker-build phase, allowing all architectures to seamlessly share the same Dockerfile. Because of this, and to be consistent with the existing Gentoo container project, Docker was chosen as the the container system for the project. The main thing that frustrated me during this segment of the project was the build times for Gentoo stages and running out of disk space when I was trying to get a proof-of-concept working. It lead to two weeks of me not being able to see my progress, which was disheartening until I finally saw it complete a build. The remainder of the project was getting the .build to .spec interpreter working.
When mattst88 brought up the potential of building a new configuration system, I was thrilled. As an end user, I have found Catalyst's .spec per stage file orgranization needlessly verbose and confusing. A new configuration system would definitely be of benefit so I got to work. Many times I'd make an error in how I was parsing some data structure or passing an argument to the .spec, and wouldn't notice until a long bit of time had passed attempting to build targets. Persistence paid off, and in the end I was able to both create the .build files mapping to the existing .specs used by the Gentoo Release Engineering team. Now every target for an architecture can easily be defined in a .build file that's much easier to produce. The possibility of using distrubuted computing to build multiple stages in parallel when a dependent stage is built is facillitated in the use of a dependency graph for building the stages. The goal of this new configuration system was to vastly simplify the amount of work needed to define a whole set of builds at once, rather relying on the traditional method of defining each stage individually and building one stage at a time. This also allowed for batch processing of every build needed to make release media or stages from a single Docker instance.
The Gentoo releng team is incredible. I plan on contributing more to the Gentoo project and documenting this project. This has been by far the broadest project I've completed yet, and it has been beneficial to my self-esteem that I made something for a project I love that I think will be very useful for many people. I am excited to see the growth of this project and would like to extend my thanks to everyone involved with making this project a reality.