Continuous-Integration

GitHub Actions (or GitLab CI) is great for Continuous Integration (CI). However, using it for Continuous Delivery (CD) for docker images isn’t necessary. And there is a better approach.

Google released a new version of the Google Auth library. It had a bug that broke Google Login on Android for API 26 and earlier. This impacted my small but popular Music Player app in Google Play. It reveals the kind of problem, I have alluded to in end-to-end testing. The only way to avoid such problems is by end-to-end testing. However, I find all Android testing frameworks to be terrible. ...

If you create GitHub Actions via GitHub’s UI by going to the URL of the form `https://github.com///actions/new`, it provides templates for setting up the build. However, the template is broken. There are four problems with the default template

Rather than pushing the code to a remote branch and then testing via Circle CI servers, it is best to run the tests locally first and make them work. Here’s how you can do that.

To use monorepo or not is an eternal debate. Each has its pros and cons. Let’s say you decide to go with monorepo, one major issue you will face over time is slow testing. Imagine a monorepo, consisting of an Android app, an iOS app, some backend code, some web frontend code. On only very few occasions will someone modify more than one of those simultaneously. Further, most of these projects confined to their directories would be using different build systems as well, for example, gradle for Android, yarn/npm for Javascript, go/rust/java/npm for the backend. The total build time and test time will only grow over time. It annoys developers making small modifications to their part of the codebase. And it slows down the development velocity drastically.

Ultimate guide to setting up and maintaining CI of your dotfiles