Github Actions for Android

GitHub Actions help you to automate your software development workflows in the same place you store code and collaborate on pull requests and issues. You can compose singular actions, and consolidate them to make your workflow. Workflow processes are computerized forms. To build, test, package, release, or deploy any code project on GitHub you can set up workflows in your repository.

Define CI (Continuous Integration)?

Continuous Integration is the process that automates the build and testing of programs each time a team member commits or pushes or pull the changes to version control. It is training for advancement where engineers share repository to integrate code as often as possible, ideally a few times each day. Every integration at that point goes for the confirmation by a computerized build and tests. However, automated testing is not mandatory in CI it is typically suggested.

One of the significant preferences of applying routinely is that you can recognize abandons rapidly and discover them all the more effectively. As each change may be little, it will prompt the particular change that causes an imperfection should be rapidly possible.

These days CI has become one of the best practices used for programming improvement and is dealt with by a lot of key standards which are update control, build mechanization and robotized testing.

Additionally, for keeping your application deployable at any point or even pushing your main codebase automatically into production whenever new changes are done into it Continuous Deployment and Continuous Delivery have developed as best practices. This permits your group to push forward rapidly while keeping exclusive expectations of value which can be checked naturally.

Use of GitHub Actions as CI

GitHub Actions characterizes work processes that can have various jobs and these workflows can be activated by any characterized occasion (pull demand , submit, push, and so forth.) or on the other hand can be planned.

GitHub Actions is the most recent contribution that can be utilized to program responses all through the GitHub stage. Written in YAML record, these reusable code can trigger new actions dependent on occasions, such as combining a pull request, testing a build, or making another repository.

Advantages:

• GitHub actions are very easy to debug. It is simply successive docker runs. It is possible to reproduce the built environment for container-based Travis, but quite difficult. On GitHub actions it’s only a docker assemble docker flee.
• Every action in a workflow is separated as a matter of course. You can utilize an entirely different registration condition for, similar to, compilation and testing. Travis CI (or other “traditional” CI) would run all actions in the same computing environment. Once more, GitHub actions are a lot simpler to reason about and debug.
• The main.workflow specification is open-source. The entire thing is wrapped into Docker in any case, so stage lock-in is apparently insignificant.
• There are now open-source re implementations of GitHub actions, for example, exercises for local testing.
• You have prepared access to the GitHub API with (to some degree restricted) confirmation out of the box.
• There might be a community or marketplace where people can share actions. like, reusing send actions work by various individuals in various biological systems.
• The visual editorial manager for main.workflows and directed acyclic graph (DAG) is maybe a superior method to display CI/CD specifically and work processes all in all. Takes some becoming accustomed to, yet sums up well.
• GitHub actions can do a lot more than just CI! You have fundamentally the entire API readily available as information sources and yields.

Limitations:

• Github Actions are free just for public repositories.
• Per month developers can utilize Only 2,000 minutes per month developers can utilize for free.
• Workflows(set of actions) can run for up to 58 minutes (including execution time and queuing).
• Up to 100 actions can run in workflows (including other meta steps and build).
• Per repository concurrently only two workflows can be running.
• As the docs clarify: “A push, deployment, or any assignment performed inside action with the given GITHUB_TOKEN won’t trigger a workflow tuning in on push, deploy, or some other upheld action triggers, Other Workflows can’t be activated by Actions.
• 64KB is the maximum limit for Docker container logs
• In an hour across all actions within a repository, developers can issue 1,000 API requests.

Moreover, GitHub Actions ought not be utilized for:

• Content or activity which is in any case denied by GitHub Terms of Service or Community Guidelines or unlawful.
• Movement which is cryptomining server-less figuring and bargains GitHub clients or GitHub administrations.
• Some other movement is random to the generation, testing, deployment, or publication of the product venture related with the repository where GitHub Actions are utilized.

At the end of the day, don’t utilize GitHub Actions in manners you realize you shouldn’t.

GitHub may screen your utilization of GitHub Actions , so as to forestall infringement of these constraints and maltreatment of GitHub Actions, GitHub may screen your utilization of GitHub Actions. Abuse of GitHub Actions may bring about limitations in your capacity to utilize GitHub Actions, or end of jobs.

Automate Workflows on GitHub Events

GitHub Actions causes you build, test, and deploy applications, yet it can likewise be utilized to mechanize different assignments basic to your designer workflows: organize and oversee issues, teaming up with your client base, robotizing releases, and more. on events from across the developer life cycle on GitHub Actions workflows can be triggered. Any GitHub App can now add its own custom events, so to meet the needs of any project developers and partners can customize GitHub.

Implementation

First of all, we need to define the YAML file under the folder .github/workflows which includes the jobs that need to be done on a particular action.

So here we will understand the YAML file step by step. in the first place, we are characterizing the estimation of the parameter name, which would be the complete name of your workflow.

name: Android Feature Branch CI

And afterward, we have to give on what event(ex. push , pull-request) workflow will be activated. Here, I need to run it when somebody is pushing code on a branch other than the master or which begins with the release in its name.

On:
  Push:
      Branches:
           - master
             - TestFlight

Then we can move to define jobs. Every workflow can have different jobs that as a matter of course are running in equal, however it could be changed to have a particular arrangement of them (for example on the off chance that one stage depends on the result of the past one). Each action runs on an alternate occasion of a virtual machine. Now, you can pick from ubuntu, windows, and macOS.

jobs:
build:
  runs-on: windows-latest

What’s more, presently at long last, characterize steps that are remembered for a job. They are undertakings which are executed in arrangement in the equivalent virtual machine.

An example job we’ve got 5 steps.

1. Checkout code
2. setup JVM(For Android executable)
3. build Gradle
4. build apk
5. deploy apk

Example YAML file

 name: CI
on:
 push:
   branches:
     - master
 
jobs:
 build:
   runs-on: windows-latest
 
   steps:
     - uses: actions/checkout@master
      - name: set up JDK 1.8
       uses: actions/setup-java@master
       with:
         java-version: 1.8
     - name: Make Gradle execuDockerfiletable
       run: git update-index --chmod=+x ./gradlew
     - name: Build Release APK
       run: ./gradlew assembleRelease
     - name: Releasing using Hub
       run: ./gradlew publishApk

First one,

— uses: actions/<branch_name>

, is an action — an atomic build block of a workflow. It’s a reusable unit which is given by GitHub, you or another public repository. The target of the first action is to permit a workflow to get to the substance of the repository. The next step is more complex, but have a simple objective — set up a JDK version to be Java 8.

- name: set up JDK 1.8
uses: actions/setup-java@
with:
java-version: 1.8

Then the third step is to build the Gradle, download the libraries which are required, indexing the project and make Gradle executable and the project runnable.

name: Make Gradle executable
run: git update-index --chmod=+x ./gradlew

Now in the fourth step, we need to build apk(s). For this, in Android, we have command ./gradlew assembly release And to run this command we need to set up code in Gradle. You can also refer this link for setup.

 - name: Build Release APK
run: ./gradlew assembleRelease

Finally, the fifth and last step would be publishing the apk on the play store. Again for this, we have command ./gradlew publish app And to run this command we need to set up code in Gradle. Refer this link for setup.

-name: Releasing using Hub
run: ./gradlew publishApk

Workflow Live Logs

Live logs provide rich feedback into the progress of builds as they run. To show status in real-time GitHub streams logs to the Actions console. For simple perusing, shading design and including emoticons logs are arranged. Live logs with numbering make it simple to talk about a build failure or test result with a companion or colleague.

Everything is set up, It’s an ideal opportunity to test! To do so, we need to create a new branch and make a commit and then push it to GitHub on the branch you have mentioned in the YAML file. Workflow will run , the outcome will be the same.

Conclusion

If you maintain a small number of open-source projects GitHub Actions is ideal. Patrons can fork the code and build conditions, and you never again need to keep up any different form framework.

But the GitHub UI works against you, once you start scaling up beyond a few projects. Also, for capturing output variables and sharing secrets any complex builds will have to find workarounds.

Having said that, GitHub Actions are in beta, and later on a great deal of these burdens likely could be explained. you’d have to seriously question whether you wanted to maintain a dedicated CI server ,if GitHub can provide a build centric dashboard and smooth out a few of the rough edges in the workflows.

GitHub Actions is one more case of the business commoditizing low hanging fruit. Consolidate the way that developers have just done the difficult work of setting their build pipelines with code with distributed computing dropping the expense of rarely executed code down to right around zero, and it’s not astonishing that code repositories have given an approach to execute those pipelines. The challenge is now to continue to add value to the CI/CD process for providers that consume the built artifacts.