Closed aiyengar2 closed 2 years ago
By adding this feature, rebasing (e.g. changing the upstream of a chart from something like kube-prometheus-stack x.y.z
to kube-prometheus-stack (x+1).0.0
) would become far easier, since you could just change the upstream and run make prepare
, resolve any patch conflicts, and you are good to go.
Resolving this issue will help resolve https://github.com/rancher/charts-build-scripts/issues/31, since rebasing would be natively supported in the scripts with this change.
The fundamental blocker for this issue is that we currently do not store the original base that was used to produce the patch.
As a result, when reading information from a .diff
file, the line numbers that look like @@ -5,6 +5,19 @@
(which normally provides context of where to apply a patch; -5,6
says that the original file was modified in the first 6
lines after line 5
and +5,19
says the new file will have 19
lines instead of the original 6
and still start at line 5
) have no meaning since we cannot identify what -5,6
corresponds to on the new patch base.
If we had the original base used to produce the patch, we could diff the new base from the old base.
This would allow us to identify all single-line modifications made (e.g. adds or removals) from old->new
Via the original patch file, we also have all single-line modifications made from old->patched.
Therefore, we can perform a Weave Merge between the two sets of single-line modifications to produce the correct conflict file.
As a result, I'm closing out this issue in favor of https://github.com/rancher/charts-build-scripts/issues/31 since the only two ways I can think to resolve this are:
1) store some sort of packages/PACKAGE/patch-base
directory that stores the equivalent of charts-original in the git repository -> bad idea, since we don't want more files than we already have
2) support this via a special rebase command that would use the existing package.yaml as the way to derive the original base and take in a rebase.yaml (or set of command line provided answers to questions) that would point at the new base
On running a
make prepare
today, if applying a patch fails we just error out.Instead, running
make prepare
should be an interactive process where, if a three way patch between the upstream, scripts, and the user is observed, the user should have the ability to remediate the errors before continuing a the call, similar to the behavior exhibited by a git rebase on encountering conflicts.make charts
, which usesmake prepare
under the hood, should also specify a non-interactive call ofmake prepare
, which will fail out if it encounters any patches.