There's a stanza in .cirrus.yml that only "runs" in
the treadmill cron job ... but that job is long gone.
The task actually runs in the buildah treadmill PR, #13808,
but that's not obvious to someone reading .cirrus.yml.
This is a maintenance burden. Remove it.
Because rootless bud tests are still important, and we
still want to run them in the treadmill PR, modify the
treadmill script itself so it (ugh) injects rootless jobs
into the buildah_bud test matrix. This is super fragile
but acceptable because I am the only one who ever runs
the treadmill script. I will notice if this breaks.
Signed-off-by: Ed Santiago <santiago@redhat.com>
- treadmill script: run root & rootless in parallel, not
sequentially. It's only four jobs, and it seems dumb
to fix root tests, repush, then discover a rootless failure.
- apply-podman-deltas: implement skip_if_rootless(), and
use it to skip a nasty longstanding flake
- bud-tests-in-podman diffs: ugly code to fix a rootless hang.
background: rootless remote tests hang
cause: stray podman server process
root cause: no idea. No clue at all. I just gave up
workaround: seek out and kill stray server processes
Rootless buildah-bud tests are not run in regular CI,
only in the buildah treadmill.
Signed-off-by: Ed Santiago <santiago@redhat.com>
In February we started running rootless bud tests in cron (#17608).
That's nice, but nobody ever looks at cron results. The idea behind
adding a rootless task was to run it in the manual treadmill, too.
This PR enables that, and more clearly documents the how and why.
Signed-off-by: Ed Santiago <santiago@redhat.com>
...gathered up from the last few months of almost-daily runs.
The principal difference is, ditching the git-am approach in
favor of git-cherry-pick. It's so much nicer! I keep forgetting
how clumsy git-am is. With the new approach, saved checkpoints
are kept as git branches, not in an easy-to-lose text file.
And, conflict resolution is MUCH EASIER. (Conflict resolution
is necessary when, e.g., the treadmill PR includes fixes for
some new vendoring that buildah has done but not podman, then
podman vendors in that same module but fixes broken tests in
a different way than I did).
Also a lot of smaller fixes for bugs reported by @Luap99.
Thank you for testing and for letting me know of problems!
Cursory review is OK: this will not break anything in the repo,
and I've been testing/finetuning these changes heavily over
the past month or two.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Buildah got vendored into podman last week, and the script
went kablooie because of ever-so-slight conflicts between
what was in the treadmill PR (#13808) and what ultimately
got merged (#14127) which was obviously better (hey, I tried).
After a buildah vendor, there really isn't any point to keeping
the treadmill commits - we're much better off just restarting
with two fresh empty placeholder commits. Do so.
Also, mild cleanup.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Situation encountered just now after buildah #3949 but
before podman #14084: go.mod changed in such a way that
other modules were updated, not just buildah, and those
changes weren't git-added by 'make vendor'. This resulted
in the dirty-tree CI test failing.
Solution: check for untracked vendor files after 'make vendor',
and git-add them. Show a friendly message that we're doing so:
+---> Adding untracked files under containers/image, containers/storage, klauspost/compress, x/sys
In order to do this safely, we run an untracked-files check
under vendor as one of the first sanity checks. If there are
any when we start the script, fail early.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Major revamp: instead of stacking a vendor commit on top of
the treadmill changes, do it the other way around: vendor,
then apply treadmill diffs.
Reason: the build-all-new-commits test. Sigh. It fails in the
common case where our treadmill changes include a new struct
element in cmd/podman/images/build.go
Why this is good: well, superficially, it's more intuitive.
Why this is horrible: omg the rebasing games are a nightmare.
When the vendor commit is on top (HEAD), it's ultra-trivial
to drop it, rebase the treadmill changes on main, then add
a new vendor-buildah commit on top. As you can see from the
diffs in this PR, treadmill-as-HEAD introduces all sorts
of complex dance steps in which things can go catastrophically
wrong and you can lose all your treadmill patches. I try very
hard to prevent this, and to offer hints if there's a problem,
and heck in the worst case it's still git so it's still possible
to find lost commits... but it's still much riskier than the
old way.
Alternative I considered: using sed magic to disable the
build-all-new-commits test. So tempting... but that would
also disable the bloat check.
Signed-off-by: Ed Santiago <santiago@redhat.com>
More safety checks for the treadmill script:
* for --sync:
- issue warning if HEAD is not a vendor commit
- if run-buildah-bud-tests fails, leave the working dir
for user to investigate. And offer a long helpful warning.
- tweak .cirrus.yml so buildah-bud tests run early, so
we can fail early. (Remember, the top commit will never
ever ever ever be merged)
* for --pick:
- check branch merge-base (of your vendor-update branch),
compare against that of the treadmill PR. If treadmill
is newer, bail, and suggest rebasing. This would've
saved us some time in #14005.
Signed-off-by: Ed Santiago <santiago@redhat.com>
This is the script I've been using (and tweaking) for the past
two weeks. It's ready for general review and use, with the
proviso that there are still corner cases I haven't tested.
See https://github.com/containers/podman/wiki/Buildah-Vendor-Treadmill
for an overview and instructions.
Signed-off-by: Ed Santiago <santiago@redhat.com>
