Kubuntu/CI: Difference between revisions

From KDE Community Wiki
No edit summary
(logo is important :))
Line 1: Line 1:
Kubuntu CI (KCI) is a continuous packaging integration system. It is hosted and maintained by Blue Systems.
Kubuntu CI (KCI) is a continuous packaging integration system. It is hosted and maintained by Blue Systems.
http://people.ubuntu.com/~jr/kubuntu-ci.png


http://kci.pangea.pub/
http://kci.pangea.pub/

Revision as of 11:15, 27 March 2015

Kubuntu CI (KCI) is a continuous packaging integration system. It is hosted and maintained by Blue Systems.

kubuntu-ci.png

http://kci.pangea.pub/

Branches

KCI uses two primary branches to continuously carry the packaging for a specific upstream branch.

kubuntu_unstable

Every package that is covered in KCI has at the very least a kubuntu_unstable branch which represents the packaging against git master (or sometimes other branches depending on what upstream uses for development).

kubuntu_stable

Selected packages will contain a kubuntu_stable branch. It carries the packaging for upstreams stable release branch. Most notably Plasma stable is tracked in kubuntu_stable branches.

Where to put things?

All in all Kubuntu has at any given point three branches in which one can land: kubuntu_$series_archive, kubuntu_unstable and kubuntu_stable. So, how does one know where to put a change?

  1. Does the change need to go the archive? -> kubuntu_$series_archive
  2. Does the change fix a warning or build problem on a CI job starting with kubuntu_stable_? -> kubuntu_stable
  3. Does the change fix a warning or build problem on a CI job starting with kubuntu_unstable_? -> kubuntu_unstable
  4. Does a CI job starting with merger_ complain that a merge is failing? -> Checkout log of the most recent build, it should give you an indication which branches fail to merge, then do a manual merge yourself.

Merges

Merge flow Plasma 5.2.1 to 5.2.80 (beta)

KCI attempts to automatically merge branches in an order that makes sense for changes to flow. This means that you usually do not need to worry about the CI branches when you do a change in an archive or PPA branch.

When packaging a new upstream release great care must be taken to first merge the correct CI branch into the correct release branch. Most of the time the release branch will be kubuntu_$series_archive. The CI branch depends on the type of release and what upstream branch it was created from.

General guideline:

  1. Is the upstream release unstable? -> merge kubuntu_unstable
  2. Is the upstream release stable and does the repo have a kubuntu_stable branch? -> merge kubuntu_stable
  3. When unsure ask on kubuntu-devel mailing list

Prevent Merge/Build Fail

Often times you can make the automerge or the build fail by introducing a change in the archive or stable branch that is not suitable for stable or unstable respectively. Notable example is backporting an upstream patch into the packaging.

The one and only important rule here is to merge locally when you think or know that you need to make an adjustment and then push all branches at once.

Let's look at introducing an upstream patch.

You import the patch as usual

quilt import ~/upstream_fix_from_stable_branch.patch
git add debian/patches/
git commit -a -m 'adding patch'

Next you forward merge this commit into stable (if there is one, otherwise simply use unstable)

git checkout kubuntu_stable
git merge kubuntu_vivid_archive

And remove the patch addition again since it is already in upstream git

git rm -r debian/patches
git commit -a -m 'drop upstream patch'

And continue forward merging into unstable

git checkout kubuntu_unstable
git merge kubuntu_stable

Last but not least you simply push all branches at once

git push origin kubuntu_vivid_archive kubuntu_stable kubuntu_unstable