Python merge use git choosing strategy default

Use git choosing strategy default in tox and pypi merge jobs for
gerrit.  This makes those jobs consistent with maven and other
merge jobs for gerrit that always build from tip of the target
branch to create artifacts from the latest & greatest code.
Building from tip (not from Gerrit commit/merge point) avoids
confusion about content when changes are merged out of order.
For example, a fix is submitted and merged, but the merge job
fails. In the mean time, a different change that happened
earlier in commit history gets merged (or the merge job is
retriggered), causing a new artifact to be pushed.  But that
artifact does not have the expected fix.

Add comments to release merge jobs why their choosing strategy
is not default.

Document the git commit choosing strategy for the release merge jobs.

Change-Id: I2e32dfa946d678fa59a290ddb53fc09387d59baf
Signed-off-by: Lott, Christopher (cl778h) <cl778h@att.com>

diff --git a/docs/jjb/lf-release-jobs.rst b/docs/jjb/lf-release-jobs.rst
index 5966cd6..2ddc6ee 100644 (file)
--- a/docs/jjb/lf-release-jobs.rst
+++ b/docs/jjb/lf-release-jobs.rst
@@ -279,6 +279,10 @@ Release Merge
 
 This template supports Maven and Container release jobs.
 
+This template uses a git commit choosing strategy that builds the merged
+commit with the release yaml file, not the tip of the target branch, so
+projects can repeat the release action in case of merge job failure.
+
 :Template Name: {project-name}-release-merge
 
 :Comment Trigger: remerge
@@ -349,6 +353,10 @@ artifacts to the PyPI release repository, tags the git repository,
 signs the tag and pushes the tag to the git server. The release merge
 template accepts neither a branch nor a stream parameter.
 
+These templates use a git commit choosing strategy that builds the merged
+commit with the release yaml file, not the tip of the target branch, so
+projects can repeat the release action in case of merge job failure.
+
 :Template Names:
 
     - {project-name}-pypi-release-merge
@@ -431,7 +439,9 @@ verify template accepts neither a branch nor a stream parameter.
 PackageCloud Release Verify
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-This template supports PackageCloud release jobs.
+This template supports PackageCloud release jobs. Checks that the specified
+packages are present in the staging repository and absent from the release
+repository.
 
 :Template Name: {project-name}-packagecloud-release-verify
 
@@ -465,7 +475,12 @@ This template supports PackageCloud release jobs.
 PackageCloud Release Merge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-This template supports PackageCloud release jobs.
+This template supports PackageCloud release jobs.  Promotes the specified
+packages from the staging repository to the release repository.
+
+This template uses a git commit choosing strategy that builds the merged
+commit with the release yaml file, not the tip of the target branch, so
+projects can repeat the release action in case of merge job failure.
 
 :template name: {project-name}-packagecloud-release-merge
 

diff --git a/jjb/lf-python-jobs.yaml b/jjb/lf-python-jobs.yaml
index 1b7c63a..d215a67 100644 (file)
--- a/jjb/lf-python-jobs.yaml
+++ b/jjb/lf-python-jobs.yaml
@@ -605,7 +605,8 @@
           submodule-recursive: "{submodule-recursive}"
           submodule-timeout: "{submodule-timeout}"
           submodule-disable: "{submodule-disable}"
-          choosing-strategy: gerrit
+          # merge jobs always build from tip
+          choosing-strategy: default
 
     triggers:
       - gerrit:
@@ -850,7 +851,8 @@
           submodule-recursive: "{submodule-recursive}"
           submodule-timeout: "{submodule-timeout}"
           submodule-disable: "{submodule-disable}"
-          choosing-strategy: gerrit
+          # merge jobs always build from tip
+          choosing-strategy: default
 
     triggers:
       - timed: "{obj:cron}"

diff --git a/jjb/lf-release-jobs.yaml b/jjb/lf-release-jobs.yaml
index b95ffe8..398a53e 100644 (file)
--- a/jjb/lf-release-jobs.yaml
+++ b/jjb/lf-release-jobs.yaml
@@ -226,6 +226,7 @@
           submodule-disable: true
           submodule-recursive: false
           submodule-timeout: 10
+          # release merge jobs build from commit not tip
           choosing-strategy: gerrit
 
     triggers:
@@ -372,6 +373,7 @@
           submodule-recursive: "{submodule-recursive}"
           submodule-timeout: "{submodule-timeout}"
           submodule-disable: "{submodule-disable}"
+          # release merge jobs build from commit not tip
           choosing-strategy: gerrit
 
     triggers:
@@ -627,6 +629,7 @@
           submodule-disable: true
           submodule-recursive: false
           submodule-timeout: 10
+          # release merge jobs build from commit not tip
           choosing-strategy: gerrit
 
     triggers:

diff --git a/releasenotes/notes/python-merge-gerrit-choosing-strategy-4d9c631e8f0c535b.yaml b/releasenotes/notes/python-merge-gerrit-choosing-strategy-4d9c631e8f0c535b.yaml
new file mode 100644 (file)
index 0000000..b436d98
--- /dev/null
+++ b/releasenotes/notes/python-merge-gerrit-choosing-strategy-4d9c631e8f0c535b.yaml
@@ -0,0 +1,19 @@
+---
+fixes:
+  - |
+    Use git choosing strategy default in tox and pypi merge jobs for
+    gerrit.  This makes those jobs consistent with maven and other
+    merge jobs for gerrit that always build from tip of the target
+    branch to create artifacts from the latest & greatest code.
+    Building from tip (not from Gerrit commit/merge point) avoids
+    confusion about content when changes are merged out of order.
+    For example, a fix is submitted and merged, but the merge job
+    fails. In the mean time, a different change that happened
+    earlier in commit history gets merged (or the merge job is
+    retriggered), causing a new artifact to be pushed.  But that
+    artifact does not have the expected fix.
+
+    Add comments to release merge jobs why their choosing strategy
+    is not default.
+
+    Document the git commit choosing strategy for the release merge jobs.