Project

General

Profile

Feature #9760

Feature #9614: Automated builds: complete phase two

Prioritize builds from release branches over others

Added by intrigeri over 4 years ago. Updated 12 months ago.

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

0%

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

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).


Related issues

Related to Tails - Feature #10492: Decide if Jenkins should test our documentation branches Resolved 11/05/2015

History

#1 Updated by intrigeri over 4 years ago

  • Parent task set to #9614

#2 Updated by intrigeri over 4 years ago

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

bertagaz, does this make sense to you?

#3 Updated by bertagaz over 4 years ago

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 over 4 years ago

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 about 4 years ago

  • 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 almost 4 years ago

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

#7 Updated by intrigeri 12 months ago

  • Description updated (diff)

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 12 months ago

  • Description updated (diff)

#9 Updated by intrigeri 12 months ago

  • 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 12 months ago

  • 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 12 months ago

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]

Also available in: Atom PDF