2017w43-44: repo-checker for Leap and full OBS for tooling tests
Leap 15.0 gained two bots
For those familiar with the Factory workflow you will have likely seen the factory-auto
and repo-checker
review bots already. Both bots were enabled for Leap 15.0, last week, by adding factory-auto
as a project reviewer which will in turn add repo-checker
after passing review. Having the repo-checker
enabled helps ensure that Leap packages are both installable and do not have file conflicts with other packages. This was made possible by a rewrite of repo-checker
and refactoring of factory-auto
. The new repo-checker
was deployed August 14th and has seen additional improvements since then.
Just as for Factory a fair number of pre-existing problems had to be whitelisted in the project config. A current accounting can be found in the repo_checker
file that should be updated daily.
repo-checker
While on the topic, the repo-checker
was enhanced to keep track of a combined build hash based on the build hash provided by OBS for each staging project and the target project. If the hash is unchanged since the last run the group will be skipped which reduced overall run from 5 hours to 1-2 hours. Depending on influx of new requests can be even shorter allowing for rather quick review waits. Decreasing run-time is also important considering the additional load from Leap 15.0 development.
Attempted to incorporate the initial support for OBS#3618: Provide comment API for retrieving comments by author, but found it lacking for the being able to remove resolved repo-checker
devel package comments.
devel-project
The devel-project
tool was fixed to resolve issue after osc
change which should result in reminder comments appearing consistently on requests with pending devel project reviews.
continuous integration
Some major improvements were made to the CI setup for both performance and coverage. The long-needed, local OBS is now merged and filled with data from OBS to provide a facsimile of Factory against which to write large functional tests. Such tests are needed to ensure the rather complex web of review bots and staging tools remain functional as unit tests are not terribly useful and very difficult to write on account of the data setup required.
Besides figuring out the quirks with using the new dockerized OBS setup on TravisCI the obs_clone
tool was introduced which makes it easy to recursively clone an entity from one OBS instance to another. This is then used to provide a proper copy of the openSUSE:Factory
project along with stagings, a devel project, and devel package. Next the build
package either needs to be installed on Travis ubuntu VM or the test run in an openSUSE docker container where that is available. This will allow using the full osc
workflow for making changes and submitting them to Factory which the bots can then review and staging tools process.
A test harness is also provided to make it simple to run tools in a testable fashion. I have much more advanced prototypes locally, but need to resolve the build
dependency issues.
On the performance side, Travis caching functionality was used to remove about 3-5 minutes from the execution time off an average of 10 minutes for around 300MB of cache.
Flake8 checks are now executed during CI thanks to dirkmueller.
virtually accepted deletes
nilxam provided the vdelreq
plugin for osc
to view the state of delete requests that have been virtually accepted.
last year
Last year at this time I proposed the Tumbleweed snapshot repositories concept and began work on what would eventually become the issue-diff tool for finding issue references in SLE packages that are not in Factory versions. This helps to ensure that Factory sees all the fixes added to packages shared with SLE.