nightly build producing a latest image resource

[mvanholsteijn]

The current dockerfile setup, always produces an image based on the 1.3.5 release (or at least the release defined by the RELEASE env var). It would be nice if the nightly release would be made of the latest master, so that I can test the changes.

[rugk]

Great idea, IMHO.

Though the problem is, we currently download and verify the release ZIPs and of course for nightly releases, it would be required to git clone the master instead…

See:

docker-nginx-fpm-alpine/Dockerfile

Line 27 in 8fe3ab9

&& wget -qO ${RELEASE}.tar.gz.asc ${PBURL}releases/download/${RELEASE}/PrivateBin-${RELEASE}.tar.gz.asc \

[mvanholsteijn]

I will make a PR.

[rugk]

Awesome thanks! Please just keep the current behavior for stable releases and adjust it only for Nightly ones.

[elrido]

IMO there are several misunderstandings with this request:

1. nightly is supposed to be the stable, signed off release on the latest stable Alpine packages, edge is the same, but on the edge of Alpine, and latest is the latest image containing the stable PrivateBin release, currently the same as tag 1.3.5 - I do update the 1.3.5 tag when important security updates hit Alpine stable or when a new Alpine stable version is released.
2. I feel very uncomfortable publishing our development branch of PrivateBin, which can always contain bugs and hasn't been as rigorously tested as the signed release versions. I would strongly discourage anyone from using our development branch in production.
3. Because the development branch isn't signed, we would have to skip the cryptographic signature check to publish it - that is a major security risk because we have no idea and control over how exactly the networking between github the repo and github the CI/CD environment looks like and who could manipulate the data in flight. We could therefore not be sure that our image would not contain something injected during the download from one to the other and would have to investigate either a mechanism that downloads and unpacks the container image to compare the contents with the development branch or figure out a different way to ensure that only the gpg signed commits of the source in the development branch make it into image.
4. If you all insist on "publishing" a development version, I would ask that we clearly label it as "development" and not "nightly", because the nightly users expect a stable release on the latest stable alpine, not suddenly a potentially buggy and feature changing software on that tag. Furthermore we should then please discuss with all of the maintainers if we want to introduce a new release/branching strategy - I would feel much more comfortable with this, if we would for example separate master as the development branch that may contain in flight or buggy or untested stuff and an integration branch, which we feel more comfortable publishing and which one of the maintainers has fully, manually tested, like the releases, before they update it and create a gpg signed tag on it for verification that they did so. If the other maintainers would support me in doing so, I'd be happy to have a more frequent schedule with that integration branch, for example once a month or every two weeks. One of the main reasons for the slow release cycle is that so far it was always me that had to do all that work and it usually takes 1-2 weeks of all my spare time to write the release notes, test and re-test the UI, upgrades, etc. before tagging the release and publishing it.

[mvanholsteijn]

I was clearly unaware of the intention of the nightly image. To keep it inline with your intentions, I suggest to revert the change in buildx.sh. What is left is the ability to create an image based on a particular branch, will that be oke?

[rugk]

Maybe name it unstable-nightly then or so? Or dev-unstable? Something like that would make it more clear…

But maybe we should indeed go one step back, because @mvanholsteijn what exactly was your use case for having a nightly Docker image of PrivateBin?

You said:

It would be nice if the nightly release would be made of the latest master, so that I can test the changes.

So what exactly do you want to test?

[mvanholsteijn]

@rugk, I wanted to test whether the official CI/CD pipeline of docker-nginx-fpm-alpine actually delivered a working version of PrivateBin.

• We have a number of changes in source code of PrivateBin.
• We have a number of changes in the dockerfile for this image.
• The dockerfile only builds with a released version of PrivateBin.
• I wanted to test whether these two sets of changes work together.

The Dockerfile now allows you to build a PrivateBin image from any branch. If you specify a semver it will build from release.

For me that is good enough, as I can now build and test the combined changes locally.

I have no explicit need for a tagged binary image in docker hub. The confusion is about the intended meaning of latest. For me latest is the latest build from master. Here, latest means the latest release build.

[elrido]

* I wanted to test whether these two sets of changes work together.

I do often have the same use case during ongoing development on a branch or such and I just use the nightly image and mount the checked out repo as a read-only volume into the container as /var/www - there is no need to change the Dockerfile and rebuild the image to do so:

docker run -d --read-only -p 8080:8080 -v $PWD:/var/www:ro privatebin/nginx-fpm-alpine:nightly

This does circumvent the hardening of separating the paths that we do in the included application for production use, but it will work for local development and even any custom conf.php settings you may have in the checked out repository, i.e. for testing GCS or other non-default features.

[mvanholsteijn]

That use case works if you run locally; When you run the container in a remote cluster it is more difficult.