UPSTREAMJOB_BUILD_NUMBER parameter is not honored when starting a test_Tails_ISO_* job manually

If I click Build with Parameters on a test job, and type a custom UPSTREAMJOB_BUILD_NUMBER, the test suite job will disregard this info and instead use the default: Git commit and artifacts of the last successful build job. Indeed, I can't find any code or config that would make Jenkins use the specified upstream job build.

Meta: I don't think we should spend much, if any, time to fix this. I'm creating this issue mostly to document it, so that developers who experience it don't waste too much time.

added C:Continuous Integration To Do labels

added Icebox label

marked this issue as related to #18190 (closed)

I looked at adjacent code (due to #18191 (closed)), so my understanding is that one way to solve this in wrap_test_suite is something like:

--- a/templates/jenkins/wrap_test_suite.epp
+++ b/templates/jenkins/wrap_test_suite.epp
@@ -98,10 +98,22 @@ use_last_release_as_old_iso() {
 
 as_root_do touch "$ALREADY_RUN_FLAG_FILE"
 
+if [ "${BUILD_CAUSE}" = "MANUALTRIGGER" ]; then
+    # Fetch injectedEnvVars from $UPSTREAMJOB_NAME/$UPSTREAMJOB_BUILD_NUMBER
+    ...
+    # Update variables accordingly
+    UPSTREAMJOB_GIT_COMMIT=...
+    UPSTREAMJOB_GIT_BASE_BRANCH_HEAD=...
+    # Fetch images from $UPSTREAMJOB_NAME/$UPSTREAMJOB_BUILD_NUMBER
+    ...
+    UPSTREAMJOB_ISO=...
+else
+    UPSTREAMJOB_ISO=$(ls tmp/tails-*.iso)
+fi
+
 git reset --hard "${UPSTREAMJOB_GIT_COMMIT}"
 git merge --no-edit "${UPSTREAMJOB_GIT_BASE_BRANCH_HEAD}"
 
-UPSTREAMJOB_ISO=$(ls tmp/tails-*.iso)
 
 if use_last_release_as_old_iso; then
     LAST_RELEASE_VERSION=$(git show origin/master:debian/changelog | dpkg-parsechangelog -l- -S version)

For this to be viable and easy we need the following:

• It should be supported by Jenkins to change the environment variables like this. I.e. the modification to UPSTREAMJOB_GIT_COMMIT and UPSTREAMJOB_GIT_BASE_BRANCH_HEAD should not cause errors elsewhere, and ideally they should end up in this job's injectedEnvVars so we don't have the wrong info there (but that is not super bad, I think we could live with that discrepancy).
• We can easily fetch stuff from Jenkins, i.e. jenkins.lizard:/var/lib/jenkins/jobs/${UPSTREAMJOB_NAME}/builds/${UPSTREAMJOB_BUILD_NUMBER}/, which maybe it isn't (for security reasons?).

I guess ideally this should be done in whatever script (or Jenkins code?) that is executed before wrap_test_suite, that sets the environment and fetches the (in this case wrong) images. I didn't want to spend much time on this, so I didn't look this up.

If we don't solve this I think we should prevent future confusion by dropping the field for UPSTREAMJOB_BUILD_NUMBER in "Build with parameters" for test_Tails_ISO jobs, and drop its sanity check in wrap_test_suite (that variable is otherwise not used).

If we don't solve this I think we should prevent future confusion by dropping the field for UPSTREAMJOB_BUILD_NUMBER in "Build with parameters" for test_Tails_ISO jobs, and drop its sanity check in wrap_test_suite (that variable is otherwise not used).

In the meantime I've done the cheapest change that can help avoid confusion and should be super safe: jenkins-jobs@5ea238db45312089018b32c16d474d146d6f7912.

I don't think it's worth trying to fix this. The exploration anonym did already proves it's not trivial, and I think we essentially never use this feature. So let's instead do that:

If we don't solve this I think we should prevent future confusion by dropping the field for UPSTREAMJOB_BUILD_NUMBER in "Build with parameters" for test_Tails_ISO jobs, and drop its sanity check in wrap_test_suite (that variable is otherwise not used).

I've verified the variable is not used either in the tails/jenkins-jobs and tails/tails repositories, so this seems safe. I'll give it a try in the next few weeks, far enough from a release process.

marked this issue as related to #18191 (closed)

assigned to @intrigeri