Generate RPM repo for releases and under dev builds #3605
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
HebaruSan
added
Enhancement
Pull request
Build
|
Let's see whether this works. We should get the nightly repo built after merge, and the stable repo after the next release. |
|
Note to self: docker run -it --entrypoint sh mono:latest |
|
OK, I guess... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Currently we provide
.rpmpackages, but somewhat ironically (given what CKAN is for), the user must download a new.rpmfile and install it manually when a new version is released.See #3197 for when we did this for APT/deb, and #2757 for when we started making RPMs.
Changes
Now a new
./build rpm-repocommand creates a_build/rpm/repofolder containing the.rpmfile (signed with our GPG key) and the additional metadata files needed to host an RPM repo. Just like we did with APT, the test builds (odd build number in version) go into anightlyrepo, and the releases go into astablerepo.I followed these instructions:
User instructions will be in doc/rpm-repo.md.
Using this (with some hacks to work around the servers and GPG keys being different), I was able to use the GNOME Software app to upgrade my 3-year-old Fedora VM from CKAN v1.26.3 to v1.31.0.