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 -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
