Skip to content
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

Merged
merged 1 commit into from
Apr 21, 2020

Conversation

cgwalters
Copy link
Member

@cgwalters cgwalters commented Apr 21, 2020

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.

src/cmd-build Outdated Show resolved Hide resolved
src/cmd-build Outdated Show resolved Hide resolved
jlebon added a commit to jlebon/coreos-ci-lib that referenced this pull request Apr 21, 2020
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.
jlebon added a commit to coreos/coreos-ci-lib that referenced this pull request Apr 21, 2020
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.
@jlebon
Copy link
Member

jlebon commented Apr 21, 2020

I think it's OK (and maybe better) if we explicitly split the fetch and build stages in CI/pipelines (in pipelines you probably always want them separate for cleaner no-op handling). OTOH, for the developer case, always requiring cosa fetch first can be annoying if you're twiddling with the manifest. Hmm, how about:

  • add a cosa build --fetch which makes it run cosa fetch first
  • have cosa fetch write the checksum of the flattened manifest to tmp/
  • have cosa build imply --fetch if the flattened manifest checksum changed (and a missing checksum also implies --fetch)

?

That way, the developer case should be pretty unaffected.

@cgwalters
Copy link
Member Author

I think we're in agreement it we should change the pipelines/CI to call both cosa fetch and cosa build explicitly in general.

have cosa build imply --fetch if the flattened manifest checksum changed (and a missing checksum also implies --fetch)

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 postprocess in the manifest I suddenly re-download packages, possibly changing what I was testing, so I don't think that's what we want either.

@dustymabe
Copy link
Member

I think we're in agreement it we should change the pipelines/CI to call both cosa fetch and cosa build explicitly in general.

Yep. We started doing that with coreos/coreos-ci-lib#24

No - what's going on here is that rpm-ostree if passed --cache-only will still fetch if it doesn't have metadata, which IMO is a bug. But it's one we were relying on.

Maybe let's just fix the rpm-ostree bug and require people to slightly change their workflows to cosa fetch && cosa build.

That would mean we just change the pipelines and fix the rpm-ostree bug and don't merge this PR or change cosa build in any other way (i.e. no implied fetch).

@cgwalters
Copy link
Member Author

Maybe let's just fix the rpm-ostree bug and require people to slightly change their workflows to cosa fetch && cosa build

Hmm....maybe. I think we need at least a transitional period though; which could look like this PR except we e.g. add

echo warning: automatically fetching; please explicitly `coreos-assembler fetch` in the future
sleep 1

or something. But I dunno if it's worth it.

@cgwalters
Copy link
Member Author

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)

@cgwalters
Copy link
Member Author

(Although, I guess in this case it was relatively easy to fix the pipelines and CI)

@jlebon
Copy link
Member

jlebon commented Apr 21, 2020

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 fetch and build steps in the README for new developers.

One remaining thing affected I can think of is the developer workflow of hacking on the manifest and just running cosa build directly as mentioned in #1379 (comment).

Second, that would mean that if e.g. I end up editing a postprocess in the manifest I suddenly re-download packages, possibly changing what I was testing, so I don't think that's what we want either.

We could try to be smarter here, but meh... maybe let's just always require a separate fetch and build then. Which I guess is what we're aligning on already. :)

@cgwalters cgwalters changed the title build: Automatically fetch at least once build: Require an explicit fetch stage Apr 21, 2020
@cgwalters
Copy link
Member Author

meh... maybe let's just always require a separate fetch and build then. Which I guess is what we're aligning on already. :)

OK done.

cgwalters added a commit to cgwalters/rpm-ostree that referenced this pull request Apr 21, 2020
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.
Copy link
Member

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.
@dustymabe
Copy link
Member

/approve

@dustymabe
Copy link
Member

Let's hold merges to COSA briefly until we run our stable release for coreos/fedora-coreos-streams#83

@jlebon
Copy link
Member

jlebon commented Apr 21, 2020

/approve

openshift-merge-robot pushed a commit to coreos/rpm-ostree that referenced this pull request Apr 21, 2020
@dustymabe
Copy link
Member

The pipeline run is done now.

/lgtm

@openshift-ci-robot
Copy link

[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:
  • OWNERS [cgwalters,dustymabe,jlebon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants