This change makes the dracut-config-generic installation in par with
Fedora. Also, by having it in bootloader packages, it is not installed in
non-bootable images, where it provides no value.
Dracut is unfortunately very host-dependant by default. The package
dracut-config-generic forces it use a generic configuration instead of a
configuration generated from the host environment.
This change should make the image generation more reproducible. For example
it was not possible to boot ami images built on Travis on AWS prior this
commit.
Also, the tests were re-generated in this commit.
The weldr API already passes custom repositories, so they end up in the
list twice. This is a bit awkward, because weldr passes something to the
store that the store already knows about. It only works this way right
now though, because the rcm API doesn't need these repositories at all.
It expects all repositories to be passed.
Import a new `NEWS.md` file with the changelog for each release. This is
targetted at distributors, so it should contain information on new
features, modified features, and anything important to packagers. This
is not a replacement for the git-changelog, but rather a human-readable
instruction to packagers what needs to be changed when using the new
release.
Additionally, copy `make release` from *osbuild* to help in creating new
release entries in NEWS.md.
This aligns the layout of `README.md` with the osbuild project. It now
has a clear structure with individual sections that we can continue to
improve on.
This tries to salvage most of the information that was previously in
README.md, but removes the bits and pieces that were either moved into
the osbuild-composer(7) man-page, or feels misplaced in a project
readme.
This adds `make man` with SRCDIR and BUILDDIR support. This is copied
from *osbuild*. Since `make man` will be the official way to build the
man-pages, lets also import `make help` and some documentation for the
Makefile.
Create a new man-page source for `osbuild-composer(7)`. This will be
the overview man-page for composer, as well as a good entrypoint to
learn about the entire osbuild setup.
For now, just include some basic information, as well as copy the bits
from README.md that make sense.
Contributions welcome! This could be a lot more verbose and helpful.
Avoid overlong lines in markdown files. This does not affect the
rendered output, but makes it a lot easier to navigate through the file
from a text-editor when editing. Furthermore, it improves *Diffs* of
our commits, and allows reading markdown without rendering it first.
On Fedora, the `%gobuild` macro turns off go modules and sets gopath to
installed libraries (in `/usr/share/gocode`).
When building the test binaries, we used `go test -c` directly, which
downloaded the libraries into GOPATH. That's wasteful and doesn't work
in mock (without internet). Replicate what `%gobuild` does by setting
`GO111MODULE=off` and `GOPATH` to the correct value.
RHEL uses modules as intended. No change is necessary.
If a compose was interrupted by restarting osbuild-composer it should be
set to failed at startup. This was not working because imgBuild is a
temporary variable, the value stored in ImageBuild needs to be modified
directly.
coveralls doesn't work from GitHub actions. Its "github" service type
uses the GITHUB_TOKEN from the action, which only has read access when
invoked from a forked repository.
codecov gets this right: it validates that an uploaded coverage file
originated from a GitHub action run by asking GitHub, and then uses its
OAuth credentials (through the Marketplace App) to comment and set
status.
Also, coveralls requires a third-party package to convert go's coverage
report to a format it understands. codecov detects the format
server-side. It also handles go's coverage format better: it highlights
lines with "some coverage" in yellow (coveralls has no concept of this).
rpmkeys in RHEL-8.1 fails if there is no trailing newline, so just
add it to all the keys for consistency. The fedora keys already
had this.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Also include the GPG keys. When we first started testing we were
testing against nightlies, whose packages were not signed. But
when using released content (which is signed) the GPG keys are
required.
Signed-off-by: Tom Gundersen <teg@jklm.no>
In PR#395 we discussed the spelling of archs vs. arches and we agreed to
use arches. This patch only renames the public method `ListArchs`in the
`Distro` interface.
Now that these are no longer used for image testsing, they do not need
to be static. Add the standard updates and modular repositories.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Now that the shipped repositories are no longer used for the tests,
we are no longer dependent on being reproducible, so using metalink
is ok.
This stil suffers from the fact that the mirror best for composer
is chosen, which may not be the same as the mirror best for the
worker. However, this sholud still be better than the round-robin
mirror, se we use this until proper metalink implementation is
in place.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Rather than use the round-robin mirror, use a fixe stable one.
We should not over-use this, but it seems the round-robin one is
simply too unstable for our tests.
Eventually, we want to use metalink here instead, but we need to
rework the file source first, so we can do that in a way that
does not make the tests dependent on the time/place the test
case was generated (currently the URL to a specific mirror ends
up pinned in the test-case).
Signed-off-by: Tom Gundersen <teg@jklm.no>
Require repository informaiton to be passed as input, rather than
read from the current directory.
Reading from the repository informaiton meant to be used by weldr
has several drawbacks.
- it makes it impractical to use the tool outside a git checkout
- it makes it awkward to adapt the repositories to different use
cases
- it means that the shipped repositories cannot be extended with
update repos, as the same repos are used for testing, and that
would render our tests non-reproducible.
Overall, we are moving towards making repositories something the
caller must always pass in, rather than something that composer
maintains. For the weldr API we need to keep working as before,
but for new APIs we are avoiding that.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This means that the unit tests no longer need to load the
repositories from the git repo, and in a follow-up, osbuild-composer
won't need to either.
By splitting the repositories used for testing from the system
repositories available through the weldr API we are able to extend
the system repositories without affecting the reproducibility of
the tests.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The API allowed composes to have multiple architectures, image
types and repositories. Turns out that's not exactly what we want
it is not clear how to combine the lits of each. Each architecture
might not combine with each image type, and it is not clear which
repositories are need for each image build. Lastly, while allowing
different image builds to have different distros in the same
compose does not appear immediately useful, there is no particular
reason to disallow that. This patch reworks the way composes are
specified.
The intention remains the same, to be able to submit several image
builds as one compose. But rather than taking arrays of image types
and architectures, take one array of image builds instead, each of
which consists of one distro, one architecture, one image build and
an array of repositories.
In a follow-up patch they will also each contain an array of upload
targets.
This means that each image build will have the same sort of structure
as a compose request in the weldr API. The reason we want to submit
an array of them rather than have them as individual composes, is that
in a follow-up patch we will introduce the concept of a "finalizer",
or "call-back" or something to that effect, which will be triggered
when all the images have been built successfully. The use-case is,
as always, koji, which requires this.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The main reason here is not to make sure we have the right set of build
packages, but rather to make sure the pointer hierarchy (distro->arch->
image type) works as expected.
This patch uses the same approach as fedora31 few commits ago. It moves
the arch pointer to the imageType struct and sets it while creating the
distro->arch->image type hierarchy in the setImageType function. The
rest of the patch is just renaming.
It uses the same approach as fedora31 few commits ago. The pointer to
distro is moved to "arch" and "arch" now contains a map of allowed
image types for each arch.
Also include setArches and setImageTypes helper functions to ease the
creation of pointers from the structures to a parent structure while
creating the distro->arches->image types hierarchy.
Previously we had to type the name of the architecture and image type
multiple times (in the definition, when inserting it into each parent
structure etc.) and it would get even worse because we would have to do
the same for all distros. These helper functions make it less error
prone by copying the name in the function automatically.
The former one was just a wrapper to the second one. In this patch I
removed the fedora31ImageType struct and instead moved the pointer to
the imageType struct. The previous solution always created a new wrapper
and returned it to the called. This new solution creates a shallow copy
of imageType, assignes arch field, and then returns the result to the
caller. It should achieve the same without the additional wrapper.
This information is now provided only when an architecture is specified,
so it is necessary to first obtain object implementing the Arch interface
then object implementing the ImageType interface and then you can get
the filename and mime type.
Tests are changed accordingly to the new API.
