Continuous Development with Powerful Github Actions for WordPress

If you have used Travis CI before, then automation and CI/CD pipelines are nothing new to you. With the continued development of software and acquisition of Github by Microsoft, it was only a matter of time before the tech giant got it’s own innovation in the Continuous Integration and Continuous Development Pipelines game. This was code named “Github Actions“.

Github Actions are the present & future

Continuous Integration (CI) workflows are considered a best practice these days. As you work with Git version control system, CI does the work for you like running tests, sending notifications, and deploying code. Deploying the code is called Continuous Deployment (CD).

For most developers and agencies shipping code to a production server is often through paid services. With GitHub Actions, Continuous Deployment is free for everyone. A direct competition to Travis CI/CD pipelines but local and native to the Github Platform.

This spells good news for all developers especially those in open source including WordPress developers. Why, you ask? Simple, the open source developers do not have to incur new costs as they ship new code and projects. They also have the chance to reduce daunting tasks of doing every day chores plugin/theme authors have to.

Missing text domains in plugins/themes? Automate it!

In the video above, we learn how to add Github Actions to our WordPress Projects. In this particular, the text-domain action sniffs our code to see if there are missing text-domains for the translated strings we have.

It then injects the right text-domains directly into our code when it is skipped by the developer or contributors writing code for the theme/plugin.

Generate translations .pot files for your plugins & themes.

Having written the right translation strings and added text-domains in our code. This video teaches you how to add Github Actions to your WordPress Project for Internationalization.

In this particular github action, it will take all the translatable strings directly in our code and make a .pot file. This file can be used by other contributors to make several translations for your plugin. This kind of action removes the demand to have several steps that were laborious to have the .pot files generated.

Given that WordPress allows for string translations on its platform without the need for .pot files however, if you have a self hosted plugin, then this becomes a critical and integral part of your workflow.

Don’t forget to checkout the Code examples in the video descriptions.

Let me know of your thoughts about the Github Actions above. Which one will you be using?