aboutsummaryrefslogtreecommitdiff
path: root/libpod/runtime_pod_linux.go
diff options
context:
space:
mode:
authorEd Santiago <santiago@redhat.com>2022-05-02 11:33:50 -0600
committerEd Santiago <santiago@redhat.com>2022-05-02 13:06:13 -0600
commite74717f348c2768b87cad7dd6997c42dc85fc50a (patch)
treef492a624b58604c492f4f69fe36be0b32ccf8a10 /libpod/runtime_pod_linux.go
parent698cb730a1a7d36bc36e447969928ccb0a6317df (diff)
downloadpodman-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 'libpod/runtime_pod_linux.go')
0 files changed, 0 insertions, 0 deletions