Feature #9760

Prioritize builds from release branches over others

Added by intrigeri 2015-07-19 03:30:23 . Updated 2018-12-03 20:40:03 .

Status:
Confirmed
Priority:
Normal
Assignee:
bertagaz
Category:
Continuous Integration
Target version:
Start date:
2015-07-19
Due date:
% Done:

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Our automated build system has several goals. IMO the most important one is to ensure that the branch used for next release builds fine. Sadly, quite often such builds are delayed by other ones that are about WIP branches.

Also, when pushing several branches at the same time, the ordering of the corresponding builds is more or less random.

So, I propose we rank automated ISO builds this way:

build_website_master = check_PO_master > stable = testing > devel > feature/buster > anything else

I.e. jobs that check stuff that’s already in production > branches we build releases from > branches we prepare future releases in > anything else

This apparently can be achieved easily with Jenkins Priority Sorter Plugin, that we’re using already (jenkins-job-builder corresponding doc.

Subtasks

Related issues

Related to Tails - Feature #10492: Decide if Jenkins should test our documentation branches Resolved 2015-11-05
Related to Tails - Bug #16959: Gather usability data about our current CI In Progress
Has duplicate Tails - Bug #17354: find a way to speed up image testing when releasing Duplicate

History

#1 Updated by intrigeri 2015-07-19 03:30:39

#2 Updated by intrigeri 2015-07-19 03:31:20

  • Assignee set to bertagaz
  • QA Check set to Info Needed

bertagaz, does this make sense to you?

#3 Updated by bertagaz 2015-07-19 04:03:52

intrigeri wrote:
> bertagaz, does this make sense to you?

Yes it does.

It seems that the JJB version we use support this plugin too.

Note that this plugin requires the latest Jenkins LTS, so we have to install an older version. There’s no information about which plugin version supports our Jenkins one. To find this, we have to dig in the plugin Git repo pom.xml file history.

#4 Updated by intrigeri 2015-07-19 05:32:47

> It seems that the JJB version we use support this plugin too.

:)

> Note that this plugin requires the latest Jenkins LTS, so we have to install an older version.

The commit that bumps that versioned dependency isn’t exactly clear. I wonder if it was just to ensure a recent enough Java is available. Anyway, I guess that Jenkins won’t want to run a plugin that declares it needs a newer one.

> There’s no information about which plugin version supports our Jenkins one. To find this, we have to dig in the plugin Git repo pom.xml file history.

Before that commit, 1.520 was required (and we have it). All 3.x versions have that commit, so apparently we need the latest release on the 2.x branch, that is 2.12.

#5 Updated by intrigeri 2015-08-28 01:36:28

  • QA Check deleted (Info Needed)
  • Type of work changed from Discuss to Sysadmin

Seems like we now have all the info we need to proceed.

#6 Updated by intrigeri 2015-12-01 12:24:29

  • related to Feature #10492: Decide if Jenkins should test our documentation branches added

#7 Updated by intrigeri 2018-12-02 14:29:47

  • Description updated

Update: since then, we started using that plugin, so addressing the problem this ticket is about is easier than last time we discussed it here. It now boils down to “assign the right priority to each job”. We can set the priority as a template variable per-branch in puppet-tails:files/jenkins/master/generate_tails_iso_jobs, just like we already do for ticket_number.

#8 Updated by intrigeri 2018-12-02 14:34:28

  • Description updated

#9 Updated by intrigeri 2018-12-02 17:52:50

  • Assignee deleted (bertagaz)

(There’s no particular reason anymore why bertagaz specifically shall do this work; it seems I mistakenly left the Assignee field as-is after bertagaz provided the input I had requested.)

#10 Updated by bertagaz 2018-12-03 20:23:57

  • Assignee set to bertagaz

intrigeri wrote:
> (There’s no particular reason anymore why bertagaz specifically shall do this work; it seems I mistakenly left the Assignee field as-is after bertagaz provided the input I had requested.)

Well, I could definitely work on that. One reason may be that, even if I had no time to work on this part of Tails lately, I’m a bit tied to this part of our infra?

#11 Updated by intrigeri 2018-12-03 20:40:03

Of course, you’re welcome to work on this :)

FTR I meant “shall” in this sense:

1. To owe; to be under obligation for. [1913 Webster]
2. To be obliged; must. [1913 Webster]

#12 Updated by intrigeri 2019-12-16 12:52:37

  • related to Bug #16959: Gather usability data about our current CI added

#13 Updated by intrigeri 2019-12-16 12:53:19

  • has duplicate Bug #17354: find a way to speed up image testing when releasing added