fpm-within-docker / fpm-within-docker

Leverage fpm inside pre-baked docker images in order to build and test native DEB and RPM packages.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

fpm-within-docker

VERY IMPORTANT NOTICE: because of time constraints, I'll keep this updated for Centos, Debian and Ubuntu LTS. Fedora and Ubuntu intermediate releases will be dropped. If I'm lagging behind, please open a ticket.

Pre-baked images for RPM and DEB package building. fpm is included!

All images are updated to the latest FPM version, currently: 1.13.1.

Donate!

Do you like this project? Is it useful to you? If you'd like to reward me, donate something from my wish list

what does this do?

If you don't want to spend your nights in learning packaging an RPM or a DEB - which is a good idea - FPM can help. But, out of the box, fpm doesn't provide a "sandbox" or any other "isolated environment" for building. Here comes this set of images.

You should still know something about package building.

For RPM see Maximum RPM, Fedora RPM Howto, or Fedora RPM Guide.

For DEB, see Debian How To Package or Ubuntu Packaging New Software.

You'd better know what docker is, as well.

Usage

I recommend you take a look at the example in the example project directory - it's an example build of a lua interpreter for Centos7 and Ubuntu Trusty. The directory contains the extracted source of lua 5.3.1, while the packaging dir contains our build scripts. The main build scripts are commented and will tell you what you should know: see build for centos 7 and build for ubuntu trusty

The build chain goes something like this:

  • First, a build-image is constructed via docker. That usually inherits from an fpm-within-docker image. This image should include whatever is needed to build the software - most probably a bunch of -dev or -devel packages. I suggest you don't install requirements which are specific to your project rather than your OS - i.e. don't do pip install or gem install for your project dependencies. Although that could provide faster build speed, it will mingle OS dependencies with project level dependencies, and later it could happen that your project builds even though you forgot a dependency in your project file.
  • Then, a build script is run into a container from that build image. Such build script can access the software source, which is usually employed to build and install the software, and performs the actual dep fetching, build, and install, so you'll get the software installed as it should be in such docker container - i.e. /usr/bin/mybinary and /usr/share/mybinary/something. Then, at the end of the build script, fpm is invoked with such paths and will create a deb/rpm package containing the binaries.
  • After that (optionally), a test-image is constructed via docker. That doesn't inherit from an fpm-within-docker image; it's an image as bare as possible should be used, since the dependency checking part is performed in the next step.
  • As a last step, a test script is invoked within a container launched from the test image. Such script should install the package that was just built, should let the package manager install any required dependency, and should run the test suite for the software, which will be tested in an environment very close to actual production scenario. This is especially useful to detect issues with missing or broken dependencies.

I suggest you just copy the whole packaging directory from the examples to your own project, then you add/remove the various distro-related subdirectories and modify them in place.

Goodies

I don't necessarily include apt-current anymore.

Limitations

Currently the images are x86_64 only. There's an exception for centos5 i386, since I had an actual use case, but its creation was very tedious, and docker doesn't officially endorse 32 bit guests.

I'll add 32 bit images only if help is provided.

Signing RPMs

Fpm supports signing rpms, but there's a minimum of setup involved; check the build for centos 7 to see how it's done. You can both sign and verify the signature is OK.

WARNING: I retained some RPM macros that used to be necessary in Centos 6 and 7 in Centos 8, but I haven't actually tested proper signing with such distro. If signing fails, please open an issue.

DEB packages are signed in the repository only, so no issue while building.

Using the fpm-within-docker images

They're available on Docker hub, so they can be used straight from your docker command line, without the need of rebuilding them locally.

fpm-within-docker images on Docker Hub

All images are are x86_64 only. Please note: some older images may exist on docker hub, but if they're not listed down there, consider them unsupported.

I'll usually add images for Centos, Fedora, Ubuntu and Debian as soon as they get out, and I'll try supporting them as long as they're supported upstream.

Available images:

alanfranz/fpm-within-docker:centos-7
alanfranz/fpm-within-docker:centos-8
alanfranz/fpm-within-docker:debian-stretch
alanfranz/fpm-within-docker:debian-bullseye
alanfranz/fpm-within-docker:ubuntu-xenial
alanfranz/fpm-within-docker:ubuntu-bionic
alanfranz/fpm-within-docker:ubuntu-focal

Thanks, in no special order

  • Kevin Pankonen

About

Leverage fpm inside pre-baked docker images in order to build and test native DEB and RPM packages.

License:Other


Languages

Language:C 48.7%Language:HTML 24.6%Language:Lua 21.9%Language:Shell 3.0%Language:Makefile 0.8%Language:Dockerfile 0.5%Language:Roff 0.4%Language:CSS 0.2%Language:C++ 0.0%