ci

So, here’s a fun problem I ran into at work: We use Github Actions to deploy all our services to Kubernetes. And in order to do a deployment, we have kube configs (as secrets) setup to connect to a Kubernetes cluster when a workflow runs. The Kubernetes config has an expiration date and will become invalid when the Kubernetes certificates are rotated (k0s takes great care of that). When they expire, the deploys fail until we update the secret on Github Actions....

I’m a huge advocate of CI and one service in particular called Travis-Ci. Travis-CI runs a continuous integration platform for both open source and commercial products. In a nutshell: Travis-CI listens for a commit to a Github repository and runs your test suite. Simple as that, no Jenkins required. At Imagine Easy we happily take advantage of both. :) So what’s wrong? For some reason, every other open source project (and probably a lot of closed source projects), use Travis-CI wrong in a way, that it will eventually break your builds....

Testing is important — most people understand that by now. A lot of people write tests for their open source code already, but in-house testing is still hard. For example, many of us had an encounter with Jenkins: it runs well to a point where it becomes harder to maintain the Jenkins than it is to write tests. Another obstacle is test setup and environments: When I write and run tests, there is sometimes only so much I can do to mock and avoid actual calls to my storage backend....