Tails

#1 Updated by bertagaz 2015-08-08 03:24:00

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 2015-08-08 04:58:40

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

#5 Updated by bertagaz 2015-08-24 07:04:11

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.

#7 Updated by intrigeri 2015-08-25 03:37:02

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