pause CI before mass pushing stuff & mark irrelevant changes NOCI

[Harald Sitter]

General reminder:

Use the tech to avoid transitional CI fail. Specifically pause CI when
you push lots of plunder via
http://kci.pangea.pub/job/mgmt_pause_integration/ and use NOCI in your
commit messages when you want to prevent an immediate build.

# Pause
http://kci.pangea.pub/job/mgmt_pause_integration/
This job halts all build integration while it is running. Builds, and
only builds. You still get semi-instant feedback on broken merges and
so forth. But builds are paused.

You absolutely want to do in every situation where you push more than
one or two repos and the repos might depend on one another. Jenkins
knows how to order builds so dependency chains are retained.

For example if Jenkins can build extra-cmake-modules and kio, it will
first build ECM and then KIO as latter build-depends on former. We
have tech that enforces this in Jenkins so you know that given this
situation KIO builds after ECM.
BUT, when you push KIO before ECM and bump the version requirement on
ECM Jenkins doesn't yet know that you on your harddisk have a version
bump for ECM, so it builds KIO and KIO fails because it can't find the
ECM dependency. Pausing builds means Jenkins won't build KIO, it will
however know that there is a change, it will queue a build for that
change but it won't actually do anything until after you abort the
pause job.
So what you should do: you run the pause job -> you push KIO ->
jenkins queues it for a CI build -> you push ECM and whatever else ->
jenkins queues those as well -> you abort the pause job -> jenkins now
processes the queue *in order* of the dependency tree -> ECM builds
first.

Not pausing is a sure fire way to turn half the jobs red through dep
ordering problems. Pausing has no downside, so when in doubt: pause
first! (don't forget to unpause though, that also makes me grumpy :P)

# NOCI
When you add the keyword NOCI anywhere in your commit message your
commit will not cause a build. You can use this to mark commits as not
worth building. But beware that most, even relatively minor changes
are not NOCI. A simple comment change in control could trigger a
lintian complaint. A file rename could break the build. So you only
want to do this when your change has no impact on the CI build.

So how can you tell...

Prime and possibly only example of this are commits that only change
the changelog but do not touch the *base* version.

e.g. 4:1.0-0ubuntu1
4:1.0 = base; if you change that it's decidedly not NOCI

You can literally change anything else in the changelog. Well, you
probably shouldn't break the format but even that you'd know in <=24
hours (see blow).

Archive uploads are a good example where you only flip the
distribution field from UNRELEASED to wily or vivid or whatever. There
is no impact on the base version so the CI has no way to fail from
such a change.

Initial uploads of new releases OTOH change the base version, e.g.
frameworks goes from 5.14 to 5.15. These must be CI'd.

Caveats:
- if you have more than one commit locally and push those commits, the
latest commit counts, if it is NOCI the entire commit set will not be
looked at. This includes merge commits! so be careful not to over use
this with non-atomic commits
- NOCI essentially prevents git.debian from telling jenkins about the
change. There are still other means the commits can trigger a build
though. albeit they usually involve me swinging a staff while shouting
a spell.
- Along that last bit, even NOCI commits are integrated as part of the
daily integration update build at 0 UTC. So fear not, if you happened
to accidentally push NOCI what shouldn't have been NOCI we'll still
find out eventually.

HS