Re: [Tails-dev] Automated builds specification

Delete this message

Reply to this message
Author: anonym
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] Automated builds specification
On 11/01/15 20:07, Jurre van Bergen wrote:
> https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/


Sorry for joining in so late. All looks good, and I only have minor
concerns.

> Developers should be able to trigger automatic builds for a branch
> whose build was dropped (eg. last commit too old) by pushing a dumb
> commit on a timestamp file in that branch.


Can't we make builds trigger via signed email too? Polluting the Git
repo like that seems ugly to me.

> How to build it
> [...]
> when building topic branch F, we need to build from branch F once
> merged into branch B. However, this merge must only be done locally, >

at least because Jenkins doesn't have push access to our Git repo.
> [...]
> This locally-merge-before-building process requires ticket #8654 to
> be implemented [...]


The thing with #8654 is that it's gonna introduce a lot of merge
conflicts. They will be simple for a human to resolve, so I'm not
worried about that, but since jenkins will bail out if there's any
conflict in the ocally-merge-before-building process, this will be annoying.

Here's an example of how the config/APT_suites may evolve for devel,
feature/x and feature/y, which both have APT suite:

devel:
------
devel

feature/x:
----------
devel
feature-x

feature/y:
----------
devel
feature-x

In this state, the locally-merge-before-building process will work fine
for all branches. However, let's say feature/x is merged (for real, not
locally!) into devel:

devel:
------
devel
feature-x

When jenkins want to build feature/y, it will locally merge feature/y
into devel, and then we'll have a merge conflict in config/APT_suites:

devel
<<<< devel
feature-x
====
feature-y
>>>> feature/y


The resolution is simple:

devel
feature-x
feature-y

In other words, for all branches based on B that modifies
config/APT_suites, whenever one of them is merged, it will reduce merge
conflicts for all other branches based on B. This will get problematic,
so we probably will need a custom git merge conflict handler. It could
probably be quite simple, since most of the time branches will just be
added (not removed, renamed) so they can be automatically resolved by
removing the merge conflict tags.

Cheers!