-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: Require an explicit fetch stage #1379
Conversation
f46df32
to
df3407f
Compare
Doing `cosa build` directly without fetching normally works, though that broke recently. Let's just do an explicit `fetch` for now. See also coreos/coreos-assembler#1379.
Doing `cosa build` directly without fetching normally works, though that broke recently. Let's just do an explicit `fetch` for now. See also coreos/coreos-assembler#1379.
I think it's OK (and maybe better) if we explicitly split the
? That way, the developer case should be pretty unaffected. |
df3407f
to
1bd0b63
Compare
I think we're in agreement it we should change the pipelines/CI to call both
First, I don't think we should delay a tested fix for a rewrite for to a more complicated fix. Second, that would mean that if e.g. I end up editing a |
Yep. We started doing that with coreos/coreos-ci-lib#24
Maybe let's just fix the rpm-ostree bug and require people to slightly change their workflows to That would mean we just change the pipelines and fix the rpm-ostree bug and don't merge this PR or change |
Hmm....maybe. I think we need at least a transitional period though; which could look like this PR except we e.g. add
or something. But I dunno if it's worth it. |
On a procedural level I think we need to keep master working. So as a general rule when things break we should either merge a PR fixing it (even if not optimal), or revert the PR that broke things right away. Keeping master broken while we debate architecture isn't right. (Also, my time to work on things is highly variable and so if we block on me it could block for hours) |
(Although, I guess in this case it was relatively easy to fix the pipelines and CI) |
Right, I don't think this is a pressing fire. CI is fixed (or to be more correct, it now does what it should've been doing already), pipelines were already split, and this PR doesn't apply to developer workdirs which already have builds. And we do advertise split One remaining thing affected I can think of is the developer workflow of hacking on the manifest and just running
We could try to be smarter here, but meh... maybe let's just always require a separate |
1bd0b63
to
a186098
Compare
OK done. |
src/cmd-fetch
Outdated
@@ -90,6 +90,9 @@ fi | |||
|
|||
# shellcheck disable=SC2086 | |||
runcompose --download-only ${args} | |||
# This stamp file signifies we successfully fetched once; after | |||
# that we won't auto-fetch again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
update comment to not mention auto-fetch
The recent "no network for builds" change broke the case where one hadn't done at least one fetch; previously this worked because rpm-ostree would fall back to fetching, but it can't without networking. Explicitly error out if a fetch hasn't been done.
a186098
to
7c73365
Compare
/approve |
Let's hold merges to COSA briefly until we run our stable release for coreos/fedora-coreos-streams#83 |
/approve |
The pipeline run is done now. /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, dustymabe, jlebon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The recent "no network for builds" change broke the case where
one hadn't done at least one fetch; previously this worked
because rpm-ostree would fall back to fetching, but it can't
without networking.
Explicitly error out if a fetch hasn't been done.