https://pagure.io/fedora-atomic-host-continuous/issue/16
Fedora started using richdeps in the `BuildRequires`, which finally
brought down our hacky tower to do Fedora RPM builds from a CentOS 7
host.
Complicating all of this is that mock in Fedora is python3. So
we'd have to maintain compatibility with both 2/3 and that sucks.
Let's do a hard 3 port for now.
"best" is currently defined to be "matches basename". This fixes
switching `micro-yuminst` to bundle `libhif` (which also has a spec in
git).
Closes: #40
Approved by: cgwalters
I have no idea why we were creating a pipe here, maybe it was used
before. Anyways it's a lot saner to just not redirect output. This
way I can actually see when I add debugging prints to mock for
example.
Closes: #39
Approved by: cgwalters
So before this I had a relatively hard line in that the
RPM version-release tags should match `git describe`. Anyone
who wants to ensure lower versions win should be using the
`priority=` key on repos.
Which works well with yum, but it turns out we don't implement
it in libhif, and hence rpm-ostree doesn't support it.
This is currently causing `skopeo-1.9` from base RHEL to win over our
CI-generated RPMs in CAHC.
We should teach libhif about priorities, but in the meantime this hack
gets us by.
Closes: #38
Approved by: cgwalters
I'm trying to build a newer golang from Fedora dist-git for CentOS
Atomic Host Continuous, but hitting an issue where it's relying on the
implicit `redhat-rpm-config` -> `go-srpm-macros` in Fedora, which
doesn't exist in CentOS.
We can work around that by specially denoting RPMs which contain
macros, and ensuring they end up in the buildroot. This is cleaner
than defining our own `foo-rpm-config` package.
Closes: #33
Approved by: cgwalters
These ultimately filter down to `rpmbuild --with|out`. The rationale
for this is that for some components I actually want to make
use of this, even though it's not traditional in Fedora/CentOS.
For example, rpm-ostree can be built with/without bundled libhif, and
for rdgo I want to not bundle.
Closes: #32
Approved by: cgwalters
When wiring rdgo to Jenkins and receving git push notifications
(e.g. github webhook), it's convenient to pass them on to resolve via
this command line flag, without having to maintain an external mapping
of which components contain which git URLs.
This allows overriding the branch (e.g. to use the `auto` branch for Homu),
or optionally fetching from an alternative location, and to fetch an
exact commit.
The first case as mentioned is for watching one upstream branch
(`master`, `auto`, `try` etc.). This second case is intended for
Jenkins PR testing, where Jenkins watches for `refs/pr/*`, and we
inherit the fetch from Jenkins.
Closes: #30
Approved by: cgwalters
We were passing the wrong value, which caused us not to find
any plugins.
Sadly we have to scrape it from the binary =(
Closes: #31
Approved by: cgwalters
In changing things to retain partial builds, we started walking
over the build list after it was complete, and deleting components
that weren't marked successful.
But builds we didn't need to do weren't marked as successful! Fix
this by retaining a set of builds we need to do, and don't try to
postprocess builds we didn't make.
This means we won't delete the cache metadata for previously
successful builds.
Closes: #27
Approved by: cgwalters
In Jenkins, git ends up printing a *lot* of output for local clones,
and it's not useful. Potentially we should use `isatty(0)` for
quiet-or-not in the future, but for now this should help make Jenkins
longs more readable.
Closes: #26
Approved by: cgwalters
Adding projectatomic/commissaire, they keep the spec in
`contrib/package/rpm`. We might as well just keep this anywhere.
Closes: #22
Approved by: cgwalters
I want to support two related but distinct things:
- Performing both i386 and x86_64 builds of the same source.
This is the base `clone` operation.
- Testing builds of a contributed patch or github PR. This
requires modifying one (or more) of the sources, and hence
is known as `--full`.
Closes: #16
Approved by: cgwalters
Some people use them even though I think it's pretty silly...if you're
making a tag, it's not really hard to include a changelog in it and
for that matter a GPG signature.
But it makes for more correct versions.
Closes: #17
Approved by: cgwalters
Currently pyrpkg is Python 2 only, but in Fedora mock is Python 3
only. This puts us in a bind, so fix it by executing pyrpkg via an
external process that's always Python 2.
Closes: #14
Approved by: cgwalters
I've often found myself in a situation where I'm trying to add a new
package, and end up pulling in some dependencies, only some of which
build. It's frustrating to keep re-building them every time.
Generalize some of the internals a bit such that we can inherit builds
from both the last successful run, as well as any partial results from
the last *unsuccessful* run.
Closes: #12
Approved by: cgwalters
An intended primary workflow is having the overlay be a symbolic link
to a separate read-only area. We need to look for certificates in the
same location.
Closes: #10
Approved by: cgwalters
Replaces the value of `$arch` in `root/mock`. This should be
convenient for doing multiple builders that share the same overlay
file.
Closes: #9
Approved by: cgwalters
TLS pinning should basically be standard practice nowadays. It isn't
significantly difficult to manage, and adds a fair amount of security.
Closes: #6
Approved by: cgwalters