At my work, we have a setup close to this.
On a successful build of jenkins (after build action), a deb is generated with FPM (awesome piece of software btw) and uploaded to an s3 bucket.
Then on another machine, a cron that run every minutes sync the s3 bucket to a local aptly repository and publish it to another s3 bucket which is the real debian repository.
This works well but the s3+cron part is probably not the smartest way and publication can take some time (like 5-10min).
I know it probably doesn't matter too much for internal use, but what does Lintian say about your packages?
Many bad things! I didn't check until now but it's a bunch of "non-standard-dir-perm" and "dir-or-file-in-var-www" and things like "maintainer-name-missing". I think it's possible to build correct debian package with FPM but for our use, we just want to build easily native deb package.
> I think it's possible to build correct debian package with FPM [...]
Of course it is possible, it's just ridiculous amount of work. It's much easier to build package with proper tools in the first place.
Re:GitLab Container Registry
by mikepurvis on Monday May 23, 2016 @04:08PM
(#11756512)
Aptly is a piece of cake compared to reprepro, because of the REST API. I just run it on a separate box, and make curl invocations from Jenkins jobs to post debs to it at the end of the build.
Depending what it is you're building, using the proper debian tooling (dpkg-buildpackage, etc) is not that much harder than FPM, and cooperating with the system gives you a lot of goodies for free (sourcedebs, cowbuilder, etc).
We're thinking about using FPM to create the debian package Package which is the retrieve as the artifacts of the gitlab-ci build stage
And then to have a separate service that will receive a webhook at the end of the (successful) build, to retrieve the artifacts and update a repository using aptly.
Does it seems the right way or is there some much simpler solution ?