DevOps, one of the important practices that every developer should follow to extensively optimize their tasks. Clearly, it’s not limited to the topic we are discussing but it’s highly used in the industry.

So you may ask what are those practices? Well, there are a lot of uses cases but one of the common use-case in software development is supposed you are working on a project & a person wants to contribute to your work then how can you verify that his commit does not break the project with your latest commit upon merging. Surely you can verify it manually but it’s highly time-consuming. At this point, you can use some type of automation to automate this process (called CI). You can also use it for deploying your project like creating a new Github release or can publish them to stores (your imagination drives you), this process is called **CD **(continuous deployment).

Not only Github other platforms like Gitlab,  Bitbucket has their own pipelines for automation. There is one from Microsoft (called Azure DevOps) which is similar to Github Actions (iirc).

In this guide, we will be using the one provided by Github called Actions.

Side Note

This is not a typical article on how to do “this”, here I’ll be focusing on concepts so that you then can write your own workflow in _ways _you want.

I wrote this article with the experience I earned by using Github Actions over the past couple of months. In case, if there is something that has a better version of representing itself feel free to let me know & I’ll update the article.

What is Github Action?

A non-technical description of it would be “It is an API which will trigger a workflow based on any event that occurs in a repository”.

• workflow: A YAML file (in.github/workflows) that contains some set of jobs that will run for each specified events.
• events: Eg: a commit/PR made to a repo, creating a new release, forking a repo, etc. are all events.
• jobs: A job is…. a job which contains a set of commands that will run on a particular OS after some constraints are satisfied.
• constraints: These are some conditions that should be met in order to run the commands or jobs.
• commands: Each command is executed on the native shell depending upon the OS you are running the workflow on (we can configure it according to our need).

Each job will be run on a fresh instance of virtual machines maintained by Github themselves (hosted runners). Each hosted runner has a defined hardware configuration. You can configure your custom runner to run your workflows in a docker container as well.

Also, there are a lot of prebuilt actions you can use from the official marketplace. We will use some of them in further examples.

#android #cli #github-actions #rust #devops