Project

General

Profile

Bug #9925

No Jenkins job is setup to build the testing branch after freeze

Added by intrigeri over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
Continuous Integration
Target version:
Start date:
08/06/2015
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
pythonlib:bugfix/9925-add-testing-branch-at-freeze-time
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

We're now frozen, and I see no job to build the testing branch. Seems that something is wrong in our algorithm that detects what should be built.

This is an urgent problem during the 1.5 release process, because in my understanding, even if I added such a job myself, it would be deleted on next jobs update.

History

#1 Updated by bertagaz over 3 years ago

I think the problem come from the not_merged_into_any_base_branch method: git branch --contains testing returns testing, which is part of the BASE_BRANCHES, so it gets removed from the list. Other "base branches" are added because they are part of the ALWAYS_ACTIVE_BRANCHES.

Not sure how to correct this. Maybe by adding an exception for testing in this method. Or just by adding testing to the ALWAYS_ACTIVE_BRANCHES, after all it would only be build daily most of the time, apart from this kind of release moments.

You can still add it by hand in our repo anyway, as long as its yaml filename is not starting with build_Tails_ISO_, our generation script won't touch it. Just did it to fix this for now.

#2 Updated by intrigeri over 3 years ago

Maybe by adding an exception for testing in this method.

I agree with the general idea, but that method seems to be the wrong place to do it: if we added an exception for testing in there, then the behavior of this method wouldn't match its name anymore. Instead, the active_branches method should add testing if it's not been merged into stable: that's where the "what kind of branch do we want to build" logic lives. See what I mean?

Or just by adding testing to the ALWAYS_ACTIVE_BRANCHES, after all it would only be build daily most of the time, apart from this kind of release moments.

No: building from the testing branch is often broken outside of freeze time, and IMO working around the bug this ticket is about is not a good reason to put any energy in changing that (we simply don't need that branch to build fine outside of freeze time).

You can still add it by hand in our repo anyway, as long as its yaml filename is not starting with build_Tails_ISO_, our generation script won't touch it. Just did it to fix this for now.

Thanks for the hint! I wonder how kludgy this is, and what are the side effects, though: IIRC we have other configuration and logic somewhere else (starting with the Jenkins Global Build Stats) that rely on such jobs to be named build_Tails_ISO_*. Hopefully this doesn't prevent artifacts from being cleaned, etc.

#3 Updated by intrigeri over 3 years ago

  • Priority changed from High to Elevated
  • Target version changed from Tails_1.5 to Tails_1.6

This was urgent a few days ago, but now that 1.5 is almost out it has become less urgent. Would be good if it was fixed before next freeze, though.

#5 Updated by bertagaz over 3 years ago

intrigeri wrote:

Thanks for the hint! I wonder how kludgy this is, and what are the side effects, though: IIRC we have other configuration and logic somewhere else (starting with the Jenkins Global Build Stats) that rely on such jobs to be named build_Tails_ISO_*. Hopefully this doesn't prevent artifacts from being cleaned, etc.

I don't think our tools will have troubles with this, because as you said they rely on the job name and not the job filename. So as long as the job name set in the config file is correct, they shouldn't see the difference.

#6 Updated by bertagaz over 3 years ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from bertagaz to intrigeri
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to pythonlib:bugfix/9925-add-testing-branch-at-freeze-time

I've pushed a simple commit that should resolve this issue. If there are new commits in testing that are not in stable, then the testing branch gets added to the list of jobs.

Not sure how you can test that. I did by adding fake commits in the testing branch, then run the same if conditional in a python shell. It behaved as expected: conditional was triggered with this new commit but wasn't before, and once the commit was merged into stable the conditional wasn't catched anymore. So I think it should work.

#7 Updated by intrigeri over 3 years ago

Thanks for the hint! I wonder how kludgy this is, and what are the side effects, though: IIRC we have other configuration and logic somewhere else (starting with the Jenkins Global Build Stats) that rely on such jobs to be named build_Tails_ISO_*. Hopefully this doesn't prevent artifacts from being cleaned, etc.

I don't think our tools will have troubles with this, because as you said they rely on the job name and not the job filename. So as long as the job name set in the config file is correct, they shouldn't see the difference.

OK, cool.

#8 Updated by intrigeri over 3 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

Looks good, merged. We'll see how it goes in practice, e.g. when 1.7 is frozen.

#10 Updated by anonym over 3 years ago

  • Target version changed from Tails_1.6 to Tails_1.5.1

Moving to the Tails_1.5.1 milestone since this actually has an effect on Tails' Git (submodule update in cce3370a).

Also available in: Atom PDF