Project

General

Profile

Bug #14875

Build reproducibility Jenkins tests: confusing UX and implementation

Added by bertagaz over 1 year ago. Updated 2 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Infrastructure
Target version:
-
Start date:
10/22/2017
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

Currently we always trigger a build of this job once we've built an ISO, and then this job decides whether it has been triggered for a good reason, writes this down using a flag file, and then N build steps each test whether they should do something or not (<=> whether the flag file exists), and if not, the build is marked as succeeded even when it has actually not tested anything. We should decide once for all whether a reproducibly_build_Tails_ISO downstream job shall be run for a given ISO.
It seems the conditional-buildstep plugin would be a "nicer solution" to use this plugin to determine if the job needs to reproduce an ISO or not, rather than the "ugly workaround" implemented first by using steps. For that to work, we need to have a newer version of Jenkins, given the dependencies of this plugin.

But it might not be the best option, especially wrt. reporting to developers/reviewers, see below.


Related issues

Related to Tails - Feature #12633: Lower the workload caused by reproducible builds Jenkins jobs Resolved 10/22/2017

History

#1 Updated by bertagaz over 1 year ago

  • Related to Feature #12633: Lower the workload caused by reproducible builds Jenkins jobs added

#2 Updated by bertagaz over 1 year ago

  • Blocked by Bug #10068: Upgrade to Jenkins 2.x, using upstream packages added

#3 Updated by intrigeri over 1 year ago

  • Subject changed from Use conditionnal-build plugin in reproducibly_build_Tails_ISO jobs to Use conditional-buildstep plugin in reproducibly_build_Tails_ISO jobs

#4 Updated by intrigeri over 1 year ago

(Fixed typo — s/conditionnal/conditional/ — and plugin ID.)

#5 Updated by intrigeri over 1 year ago

(This is scheduled to be done after the end of the contract.)

#6 Updated by intrigeri over 1 year ago

  • Tracker changed from Feature to Bug
  • Subject changed from Use conditional-buildstep plugin in reproducibly_build_Tails_ISO jobs to Decide once for all whether a reproducibly_build_Tails_ISO downstream job shall be run for a given ISO
  • Description updated (diff)

While reading about Jenkins stuff for unrelated reasons I came to think about this and after taking a step back, I don't think it should be the responsibility of a reproducibly_build_Tails_ISO build to decide whether it shoud do anything at all. Because the way I understand Jenkins semantics, a job succeeds or fails, and it has no way to say "oh actually I don't feel I'm needed today, I'll pass"; so as a developer/reviewer, when looking at the Jenkins dashboard, a reproducibly_build_Tails_ISO job whose last run is marked as successful is confusing: to know whether my branch has actually been tested, I need to look at the "Last Duration" field; meh. As a developer/reviewer, I would like to be able to treat the results of this job like every other Jenkins job: Jenkins should tell me whether it has run, and whether it has succeeded, in a way that means what I'm interested about (i.e. the ISO was rebuilt identically success, or was rebuilt differently failure, or the ISO was not rebuilt at all == there's been no build of that job).

So I think a build_Tails_ISO build should be the one deciding whether it's worth checking if the ISO it has built should be tested for reproducibility. The good news is that apparently there's a way to do it, that's already supported by the version of the Parameterized Trigger plugin we use:

  • during the (first) ISO build, check if the ISO shall be tested for reproducibility and iff. yes, create a dummy properties file (whose content actually does not matter, it'll be used as a flag file)
  • have the trigger-parameterized-builds for project: reproducibly_build_Tails_ISO_{name} "read properties from a file", i.e. use property-file in jjb lingo; and enable fail-on-missing for project: reproducibly_build_Tails_ISO_{name} in there, so that the downstream job is not triggered when our flag file has not been created; I think that the "fail-on" phrasing is misleading BTW, as the Jenkins UI merely says "Don't trigger if any files are missing"
  • and then all the conditional handling in reproducibly_build_Tails_ISO can be removed, and a given build of that job, when it's been triggered, can focus on doing what it is about, and not on determining whether it was triggered for a good reason or not.

=> I think we should not use the conditional-buildstep plugin at all in this case. I think the resulting UX will be much better (and consistent with what we have been trained to) and the code+config will be simpler than if we used conditional-buildstep. And then this ticket should not blocked by #10068 :)

What do you think?

#7 Updated by intrigeri over 1 year ago

  • Description updated (diff)

#8 Updated by anonym over 1 year ago

  • Target version changed from Tails_3.5 to Tails_3.6

#9 Updated by bertagaz about 1 year ago

  • Target version changed from Tails_3.6 to Tails_3.7

#10 Updated by intrigeri about 1 year ago

  • Parent task changed from #5630 to #12633

#11 Updated by intrigeri about 1 year ago

  • Subject changed from Decide once for all whether a reproducibly_build_Tails_ISO downstream job shall be run for a given ISO to Build reproducibility Jenkins tests: confusing UX and implementation
  • Description updated (diff)

#12 Updated by intrigeri about 1 year ago

  • Parent task deleted (#12633)

#13 Updated by intrigeri about 1 year ago

  • Related to Feature #12633: Lower the workload caused by reproducible builds Jenkins jobs added

#14 Updated by intrigeri about 1 year ago

  • Blocked by deleted (Bug #10068: Upgrade to Jenkins 2.x, using upstream packages)

#16 Updated by bertagaz about 1 year ago

  • Target version changed from Tails_3.7 to Tails_3.8

#17 Updated by intrigeri 11 months ago

  • Target version changed from Tails_3.8 to Tails_3.9

#18 Updated by intrigeri 9 months ago

  • Target version changed from Tails_3.9 to Tails_3.10.1

#19 Updated by intrigeri 7 months ago

  • Target version changed from Tails_3.10.1 to Tails_3.11

#20 Updated by CyrilBrulebois 5 months ago

  • Target version changed from Tails_3.11 to Tails_3.12

#21 Updated by anonym 4 months ago

  • Target version changed from Tails_3.12 to Tails_3.13

#22 Updated by u 2 months ago

  • Assignee deleted (bertagaz)
  • Target version deleted (Tails_3.13)

Also available in: Atom PDF