diff options
author | Ed Santiago <santiago@redhat.com> | 2022-05-02 11:33:50 -0600 |
---|---|---|
committer | Ed Santiago <santiago@redhat.com> | 2022-05-02 13:06:13 -0600 |
commit | e74717f348c2768b87cad7dd6997c42dc85fc50a (patch) | |
tree | f492a624b58604c492f4f69fe36be0b32ccf8a10 /build_osx.md | |
parent | 698cb730a1a7d36bc36e447969928ccb0a6317df (diff) | |
download | podman-e74717f348c2768b87cad7dd6997c42dc85fc50a.tar.gz podman-e74717f348c2768b87cad7dd6997c42dc85fc50a.tar.bz2 podman-e74717f348c2768b87cad7dd6997c42dc85fc50a.zip |
Treadmill script: revamp
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>
Diffstat (limited to 'build_osx.md')
0 files changed, 0 insertions, 0 deletions