Jenkins prep and cleanup patches #1900
Closed
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
Use `dnf` consistently. Drop a couple of other conditionals.
Jenkins' `checkout scm` gives us the exact commit that we're testing. Allow passing that to the submodule commit message checker so it doesn't use `HEAD` (which is likely GitHub's merge commit).
These are part of the latest release now, so we can nuke them and skip one `dnf install` invocation.
This is a bit of a hack, but does the trick now. Eventually, we'll need to either bump rdgo to f30, or set up continuous builds some other way (e.g. Packit or Jenkins pipelines).
The build system doesn't support this anymore. Also add `-T0` for multi-threading.
Not actually planning to use this for now. Noticed it in passing.
So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out.
From Rust v1.37, `cargo vendor` is now baked. Stop building it, and tweak the vendoring script to adapt to the new UX.
This is one of the tests right now that assumes it's running on f29. We might be sort of in this awkward dual path for a while where we want tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS).
Follow-up to the recent licensing changes. This is the first spec file change since moving it upstream.
|
bot, retest this please |
1 similar comment
|
bot, retest this please |
cgwalters
reviewed
Sep 9, 2019
| echo "Running yum -y distro-sync... $(date)" | ||
| yum -y distro-sync | ||
| echo "Done yum -y distro-sync! $(date)" | ||
| echo "Running dnf -y distro-sync... $(date)" |
There was a problem hiding this comment.
I know this will be an endless battle but...we probably do want to support rhel8 builds at some point, and it's still yum there...not that it matters really. I just find it easier personally to type yum since it works on rhel7 too.
|
⚡ Test exempted: pull fully rebased and already tested. |
rh-atomic-bot
pushed a commit
that referenced
this pull request
Sep 9, 2019
Jenkins' `checkout scm` gives us the exact commit that we're testing. Allow passing that to the submodule commit message checker so it doesn't use `HEAD` (which is likely GitHub's merge commit). Closes: #1900 Approved by: cgwalters
rh-atomic-bot
pushed a commit
that referenced
this pull request
Sep 9, 2019
These are part of the latest release now, so we can nuke them and skip one `dnf install` invocation. Closes: #1900 Approved by: cgwalters
rh-atomic-bot
pushed a commit
that referenced
this pull request
Sep 9, 2019
This is a bit of a hack, but does the trick now. Eventually, we'll need to either bump rdgo to f30, or set up continuous builds some other way (e.g. Packit or Jenkins pipelines). Closes: #1900 Approved by: cgwalters
rh-atomic-bot
pushed a commit
that referenced
this pull request
Sep 9, 2019
The build system doesn't support this anymore. Also add `-T0` for multi-threading. Closes: #1900 Approved by: cgwalters
rh-atomic-bot
pushed a commit
that referenced
this pull request
Sep 9, 2019
Not actually planning to use this for now. Noticed it in passing. Closes: #1900 Approved by: cgwalters
rh-atomic-bot
pushed a commit
that referenced
this pull request
Sep 9, 2019
So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
rh-atomic-bot
pushed a commit
that referenced
this pull request
Sep 9, 2019
From Rust v1.37, `cargo vendor` is now baked. Stop building it, and tweak the vendoring script to adapt to the new UX. Closes: #1900 Approved by: cgwalters
rh-atomic-bot
pushed a commit
that referenced
this pull request
Sep 9, 2019
This is one of the tests right now that assumes it's running on f29. We might be sort of in this awkward dual path for a while where we want tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS). Closes: #1900 Approved by: cgwalters
rh-atomic-bot
pushed a commit
that referenced
this pull request
Sep 9, 2019
Follow-up to the recent licensing changes. This is the first spec file change since moving it upstream. Closes: #1900 Approved by: cgwalters
|
Dist-git follow-up to this in https://src.fedoraproject.org/rpms/rpm-ostree/pull-request/37. |
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.
These are prep patches for hooking up to Jenkins pipelines. Most are pretty straight-forward but there is one commit I'd like to call out specifically:
packaging: Move canonical spec file here
So this is a somewhat significant change, but I'd like to try having the
canonical spec file upstream. A few reasons for this:
we're in a pretty good position for knowing how the software should
be packaged.
This has important ramifications, including that it'll be easier to
integrate with continuous build services like Packit, but releases
will also be less fraught with last-minute packaging fixes.
the "artifact" that gets moved down the pipeline into later stages
(e.g.
cosa build). We could even eventually make it an actualexternal artifact so that anyone can easily download RPMs from any
random PR for testing. (And in fact, with a thin yumrepo layer on
top, it could be used to replace Packit/rdgo entirely).
Not that this approach doesn't have issues as well (e.g. on the dist-git
side, we'll need some minimal tooling to merge in the changelog), though
I think it's worth trying out.