Design for integrating rpmdistro-gitoverlay type flows

[cgwalters]

Taking influence from Travis is great, however, I think we really should also take this opportunity to make in infrastructure specific to what we do. One of those things we do involves RPMs.

So I'd like to support some of the flows that rpmdistro-gitoverlay implements. Ideally, share code as welll. (For example, rpmdistro-gitoverlay understands how to do recursive git mirroring).

This specific ticket is about supporting something like:

distgit-dependencies: true

To automatically install all BRs from the spec file of the distro matching the container.

[jlebon]

Taking influence from Travis is great, however, I think we really should also take this opportunity to make in infrastructure specific to what we do. One of those things we do involves RPMs.

Right, the intent has always been to tailor it for our needs and enable CI/CD!

This specific ticket is about supporting something like:

distgit-dependencies: true

To automatically install all BRs from the spec file of the distro matching the container.

Yeah, there are many integration points possible here and this seems like a sensible first one.

How about we add a new top-level spec key that takes a relative path or remote URL? And then have e.g.

container:
  image: fedora:24
  install-buildreqs: true

# and the host equivalent

host:
  distro: fedora/24/atomic
  install-buildreqs: true

And yeah, as an optimization, if spec is not given, use the fedora dist-git spec based on the same name as the repository.

I think one major goal we should have here is to enable the atomic/vmcheck workflow, i.e. build in a container, install to a new tree, reboot into that tree, and run tests (with using unlock as an optimization if overlayfs is acceptable). As a first step, we can just make install DESTDIR=/host, though improving on that we can build actual RPMs and even make them available for other tests.

Not in scope for this, but maybe let's keep it in mind as we add functionality.

[jlebon]

Forgot to update this ticket with the outcome of a chat I had with Colin about this. Major points were:

1. Rather than rebuilding the world on each PR, we can leverage FAHC/CAHC and only rebuild the project in question.
2. In view of (1), using rdgo doesn't make much sense if we're building only a single component. There is however opportunity for code sharing, e.g. when it comes to spec editing.
3. In view of (2), we should consider storing the canonical spec files in the tree, to allow for atomic changes to code + pkg and thus strengthen rdgo-based streams.