On Thu, Feb 26, 2015 at 05:21:23PM +0100, anonym wrote:
> 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.
It surely isn't the best for the git history or commit point of view, but
OTOH it express in git's semantic the fact that a branch is active for
more people than Jenkins and the sender of the email. So for example the
release manager can also easily get that info and add the branch on his
radar.
Signed email could be an optional feature, like nice to have, but maybe
not a blocker to deploy the automated builds. It will surely be a bit more
tricky and might delay things a bit.
> > 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:
>
> [...]
>
> 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.
It seems that this kind of easy merges could be resolved by configuring
.gitattributes to use the union merge for config/APT_suites.
https://code.google.com/p/endgame-singularity/source/browse/.gitattributes
I'm not sure how it handles corner cases though, it might deserve some
tests to see how it fits. Otherwise intrigeri was mentionning another
possibility in Git.
Thanks for the meaningful feedbacks!
bert.
