Always tracking master branches and upstream is great to keep stuff up to date and things fresh. As Lagoon grows we're running more and more into issues of not having versioned Lagoon Releases or Lagoon Images, here just a short recap of the pain that we suffered in the last weeks:
- A recent update of curl caused some deployment issues for some projects, the developers unfortunately had to wait while we figured out what the problem was and released a Hotfix of the affected Images - #925
- As more and more people are using, the fact that
openshiftBuildDeployalways used the newest published master version ofoc-build-deploy-dind, made it very complicated to keep the newest code backwards compatible with a slightly older Lagoon version. - A build of the master branch of Lagoon automatically published new Lagoon Images. This meant we could only merge into master when we actually wanted to publish new images. While this maybe was okay when we had 2-3 PRs to release, recent Lagoon releases had up to 35 PRs that needed to be merged all at once, this caused confusion and a lot of complexity which wasn't necessary.
Therefore today we're addressing these issues with three updates:
- Lagoon Base Images (
php,nginx,nodejs, etc.) exist with a:latesttag (like they always did), plus a new Lagoon Version Tag, likeamazeeio/nginx:v0.21.0. Important is that this is not the version number of the service, but the Lagoon Version. For Images that already provided tags for different versions of the service, we now publish a tag with a version suffix like:amazeeio/amazeeio/php:7.1-fpm-v0.21.0plus the already existing "latest" version without a suffix:amazeeio/amazeeio/php:7.1-fpm. We still suggest to always use the latest versions of the images as we do not maintain older version of images for security updates, but there are some cases where the versioned base images are coming in handy. - Merges into
masterbranch do not automatically publish new Lagoon Images. New Images are only pushed if an actual release (a git tag) has been pushed. This improves the PR workflow drastically as we can now merge into master as soon as a single PR is coming back green from the CI system. Also all PRs and Branch builds still push images to theamazeeiolagoonDockerhub Organisation, likeamazeeiolagoon/php:7.1-fpm-master. As you can see they are suffixed with the branch or PR name. These Images should only be used for testing purposes! - All Version builds of Lagoon Images now include a new
LAGOON_VERSIONenvironment variable which includes the version number of the Lagoon Version they have been published from. This can be used for all kind of purposes in your code and is used byopenshiftBuildDeployto use the sameoc-build-deploy-dindimage version that works together with the Lagoon Version that is running.
We know that many people where wondering since some time why these changes have not been implemented before and why it took so long for this to implement. We're sorry that we took a bit of time to realize and figure out a system that works for us.
We're very excited about the changes and look forward to a versioned future!
Beside all of that there are of course additional changes:
Features:
- Versioned Lagoon Images (read above) #930
Changes:
- none
Bugfixes:
- Fixes log link missing from RocketChat messages, described in #858
Improvements:
- Further improvements on the integration with th Backup-as-a-Service (K8up) system (#929) - which now creates individual S3 buckets for each Lagoon Project and improves the performance of Backups and Restores drastically (like 1000x faster for bigger Lagoon implementations).
- Updating Composer from V1.6.5 to v1.8.4 in all php cli images (#927)
- Logstash upstream images had some changes and we need to follow them (#926)
- Fluentd elasticsearch plugin has some new settings and defaults, we're using them now (#926)
- The Build Logs include some tokens, while they cannot really be used for anything, we're hiding them now (#924)
- Multiple scheduled builds are now skipped and only the last one run (#932)
Documentation: