Packages

From Archivematica
Revision as of 10:07, 6 October 2017 by Scollazo (talk | contribs) (→‎Package development)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Archivematica packaging

Some Archivematica dependencies can't currently be obtained from the official Ubuntu/Centos package repositories, so we build them and make them publicly available in the archivematica-externals repository.

Those external dependencies, and also the official Archivematica packages for Ubuntu and Redhat/Centos can be built using the scripts provided by the am-packbuild repository.


Roughly, the workflow for debian package building is as follow:

- build docker image
- clone code
- tweak code when needed
- update changelog
- build debian/rpm package


There is a Jenkins job triggered each time a new commit is made to the qa/1.x and qa/0.x. The job is workflow is based on the am-packbuil repo, and each time a new commit is made to the qa/1.x branch, the deb and rpm packages are built and uploaded to a development repo that can be configured as follow:

RH/Centos:

http://jenkins-ci.archivematica.org/repos/rpm/release/

Ubuntu 14.04 (Trusty)

 deb http://jenkins-ci.archivematica.org/repos/apt/release /

Ubuntu 16.04 (Xenial)

 deb http://jenkins-ci.archivematica.org/repos/apt/release-xenial /

The development key can be installed on Ubuntu systems with:

wget -O - http://jenkins-ci.archivematica.org/repos/devel.key | sudo apt-key add - 

The jenkins job trigger gets the release version and number using the git describe --tags (for 1.7, the VERSION values are hardcoded to 1.7.0/0.11.0), and builds the package with make VERSION=<version number> RELEASE=<release number> BRANCH=qa/1.x, and then signs them with the archivematica development key.

This is a first step working towards a full git integration, where a new official releases are triggered by the creation of a tag in the repo, and don't need manual intervention besides configuring the gpg production signing keys in advance.For now, for official releases, the build job can be configured with the gpg id of the production key, in order to build packages that can be added to the production repo.

Package development

The Makefiles available in the debs/ and rpm/ folders cover all the steps noted in at the beggining. Some of them can be triggered individually by running an specific make task (make build-docker-image, or make build)

For adhoc packages (using a different branch than qa/1.x), jenkins jobs can be triggered using the needed parameters for version, branch, and package repository.

GPG Key management

There are two keys being used, one in the development stage while the other is only for production ready packages. The reason behind that is avoiding misshappenings with development packages reaching production systems.

To avoid exposing the private gpg keys needed to build the packges, there archivematica makefiles have two methods for injecting them. One is a file called GPG-KEYS in the root directory, useful for local development, and the other loads the environment var $GPG_KEY, and imports it, so we can inject the key to the jenkins build process without exposing it.