In October, GitHub announced GitHub Actions, their upcoming integrated solution for running automation triggered by things you do on GitHub. I would call it CI/CD, but that's only part of what it can do. I've had beta access for about 2 months now, but didn't really play around with it until around the Christmas period.
Earlier this April, the CI/CD service Wercker released their new Steps Store. As I long ago built a step for generating Hugo sites like my own, I decided to upgrade it and see what has changed.
A 5 minute introduction about AWS CodeBuild. What is it, how does it work, and what are some of the good and less good things about it.
When using Docker containers to trigger Ansible configuration, you can run into an issue regarding Docker's virtual filesystem and SSH sockets. This shows how I worked around that problem.
Pipelines seems to be almost as popular as machine learning right now and earlier this week Atlassian announced that Bitbucket now has them built in as well. Or rather, it's in beta. Naturally, I was interested so I decided to take it for a spin. This article shows how I set it up for one of my existing projects, and I'll go into the good parts and the limitations.
In my ongoing quest for automating all deployment related matters, I discovered I needed a way to pull in single files from S3 for my Wercker builds. As I couldn't find a step for that, I built one.
While Aqua neatly makes the initial setup for my Lambda functions easier, that still left me with the deployments. In order to deal with that, I therefore made a simple deployment step for Wercker. I'll first go over how to use it, before showing how it works.
At the Docker birthday event last week I decided that instead of working on the Birthday Challenge I would make Igor work on Docker as well. That meant I need to deploy two versions from a single build however, and in this article I'll explain how that works.
For Igor I wanted to make sure that there is always a compiled, and up to date, binary ready for download. The obvious way for me to do this was using Wercker, but this turned out to be a bit more work than I expected, so I'm documenting it here.
Different parts of your project might require different environments. Additionally, when building web projects for clients you don't always have control over the server your project will run on. Both of these issues can be solved, and this article will show how you can use Docker to have a better and more efficient Jenkins setup.
In this tutorial we will set up a basic Hugo project and then configure a free tool called Wercker to automatically deploy the generated site any time we add an article.
At the start of the year I mentioned writing a step for Wercker to help with automating deployments for Hugo sites such as this site. In the community forums people requested that I write a tutorial for it, and that has now gone up on the site.
It also works as a general introduction of using Wercker steps, so even if you’re not interested in Hugo itself the tutorial might be useful for that purpose.
I mentioned that I was planning on building a step for making it easier to deploy Hugo sites using Wercker, and I've done so.
When generating frontend assets, you don't want to add these generated files to your repository but it's not always possible or easy to generate them on the production server either. In this article I'll describe how to solve this issue using Jenkins.