Revision as of 15:07, 27 September 2016

Neon uses a Jenkins continuous integration system to build its packages

The Setup

drax.kde.org is the master server, owned by Blue Systems and administrated by KDE Sysadmins. It runs a Jenkins instance which is a Continuous Integration website at build.neon.kde.org that has many jobs to build the packages and run other functions, either on demand or at pre-scheduled intervals.

The code behind build.neon is from pangea-tooling which also runs the code for DCI Debian CI, KCI Kubuntu CI, ACI Appstream CI, and MCI Mobile neon Plasma CI.

The Jenkins jobs farm off the hard build work to 4 DigitalOcean build servers. It runs most jobs inside a Docker container to give a fresh build environment.

To use the scripts to access Jenkins you will need to set ~/.config/pangea-jenkins.json using access key available inside Jenkins to administrators.

The setup of the machines is maintained in pangea-kitchen which uses Chef to set up the servers with software all configured.

The Jobs

The Jenkins jobs are created by running the pangea-tooling script jenkins_jobs_update_nci.rb. This creates some manual Jobs specified in the script such as the ISO jobs but mostly uses factories to create batches of jobs based on archives.

The YAML files in pangea-conf-projects define what jobs get created.

For each package there is a parent MultiJob which runs some sub jobs.

parent job this is set to checkout the relevant archive from KDE Git as source/ (for Developer Editions), then check out the relevant archive from KDE neon Git as packaging/. It then runs a number of child jobs...

src will create the source package. For User Edition this means running uscan to use the debian/watch file to download the relevant tar, for Dev Editions it uses the source the parent job checked out. It then builds the source package.

bin job will extract the source, install the build dependencies and compile the package. It finishes by checking the output from lintian and fails on any errors, you can override errors with lintian-overrides files in the normal .deb packaging method (see dh_lintian). It also checks for any list-missing files and fails if there are any, override by adding a debian/not-installed files. It also fails if cmake reports build-dependencies it needs, override with debian/meta cmake-ignore.

adt job runs Debian's test framework autopkgtest. See Ubuntu guide for some details. It runs adt-run on the binaries which installs them and runs the relevant test suite as defined in debian/tests/. It doesn't fail if tests fail.

pub job will upload to aptly, see The Archive below.

lintqml job will scan for QML dependencies which have not been satisfied by the package dependencies, it will print a JSON output of any missing QML modules it requests. The packager should add these to the packaging manually and rebuild.

snap job will package it up as a Snappy Snap package. This is experimental, you can see the output at distribute.kde.org.

Other Jobs

watcher jobs are made for packages in User Edition. They use debian/watch files to check for new releases and if one is found add a new changelog entry, merges from Neon/stable, then runs the release build job. See man uscan for info on watch files. It will fail it is finds an "unstable" line in the watch file as we don't include these in User Edition.

mgmt jobs run various management tasks. mgmt_tooling is run whenever there is a commit made to pangea-tooling, it blocks new jobs being started while it's running which can be a blocker so you can cancel it if you check the commits to pangea-tooling are not relevant. It fails if ruby testing fails. It runs mgmt_docker which updates the docker images used for builds. mgmt_pause_integration can be run manually and just blocks jobs from starting, remember to kill is when you're done. mgmt_jenkins_prune_archives and mgmt_jenkins_prune_logs clear some space on the server and run periodically. mgmt_progenitor is run daily and runs mgmt_build_xenial_release and stable/unstable. It does something important. TODO what?

iso jobs builds the installable ISOs. See Neon/InstallableImages. The Dev Editions are run daily and the User Edition is run weekly.

The Archive

aptly instance forked? repos? ./ci-tooling/ci/repo_console.rb --gateway ssh://drax:9090 https://github.com/KDEJewellers/aptly-api/

Repo.list
repo = Repo.get("unstable_xenial")
repo.packages()

The Packaging

how to package ci variable overlapping files