preface

Talking about CI/CD, many students may look like this, right?

How to say, as an Android developer, many students know very little about CI/CD. In fact, with CI/CD, you can do a lot of interesting things.

First of all, what is CI/CD?

CI/CD includes CI and CD.

CI (Continuous Interaction) stands for Continuous integration, which is an automated process belonging to developers. In today’s Android development model, multiple people are working on a project at the same time, so what can we ask the machine to do to maintain the security and stability of our project every time we submit code? The answer is shown in the figure above. When we submit a piece of code, the automated tool triggers a build, tests, and then merges the code for us.

CD stands for Continuous Delivery. When a developer submits code, an automated tool automatically tests it for errors and uploads it to a repository. Finally, it is deployed by the operations team in a real-time production environment. The other layer is Continuous Deployment, which represents Continuous Deployment and is the release of the repository to production.

After listening to the above explanation, can Android developers understand CI/CD?

Obviously not ah, does it matter, it doesn’t matter, anyway from the entry to give up, 🙂

CI is relatively easy to understand, using the actual Android experience to explain that continuous delivery is the updated Master branch code packaged into the channel package required by each application market, continuous deployment is the package made in the last step, automatically uploaded to the corresponding application market.

CI/CD implications for Android development

First of all, FOR developers, CI can detect errors as early as possible. Every time we submit a piece of code, automated tools will initiate construction, automatic testing, and finally integrate the code to ensure the stability of our project. Don’t code up, make up all of them, but still feel feel feel feel feel feel feel feel feel write down!

Secondly, for operation and maintenance personnel, CD can improve their work efficiency, and automation tools can reduce their unnecessary workload.

This meaning is a little general, to put Android:

  1. Standardize management of Android projects
  2. Automatic trigger multi-channel packaging
  3. Automatic uploading to app markets should also be possible. I’ve seen some platforms that can upload our app to various app markets with one click.
  4. I recently studied componentization under automatic upload AAR
  5. And a series of precision tests shared by the team’s big doctor
  6. .

The CI/CD tool helped us a lot.

See here, Bugly also suggests that we put symbol table uploads into continuous integration.

The most common continuous integration tool is Jenkins, because it is open source and free. Almost all the plug-ins you want can be found in the open source community.

But this time it’s not Jenkins.

Making the Action profile

Github Action Github Action

Automate, customize, and execute software development workflows in the GitHub Actions repository. You can discover, create, and share actions to perform any job you like (including CI/CD) and merge the actions into a fully customized workflow.

So, Github Actions is Github’s continuous integration service, so how is it different from other continuous integration tools?

Any set of actions such as setting up the JDK, running Shell commands, or performing automated tests are called actions. Setting up JDK actions must be universal, hence the free Github Action market. Allows developers to upload their packaged actions to the marketplace, which can be referenced by other developers as needed.

As you can see, there are nearly 1W actions in the current market, which can meet the daily needs of development.

In addition, Github Actions also provide templates for common projects. When you click on your own Action, it suggests some templates:

Also allow yourself to choose some popular templates.

Introduction of grammar

See here, many students have already started to want to try, don’t worry, let’s introduce grammar again!

With these nouns in mind, let’s see how they relate:

A WorkFlow consists of an Event and a Job. Each Job consists of a Runner and a series of steps. Each Step consists of an Action or Shell Command.

Now that we have some understanding, let’s look at grammar.

The Github Action configuration file, called the WorkFlow file, is stored in the.github/workflows directory of the repository. The file uses the YAML syntax.

Let’s use a default Android template to see what it looks like:

name: Android CI Set the WorkFlow name

on: # set Event
  push:
    branches: [ master ] 
  pull_request:
    branches: [ master ]

jobs:
  build: Set the name of the Job

    runs-on: ubuntu-latest # set server

    steps:
    - uses: actions/checkout@v2 Action gets the source code for the current branch
    - name: set up JDK 11 # Action Sets the JDK
      uses: actions/setup-java@v2
      with: The parameter is specified by the creator of the Action
        java-version: '11'
        distribution: 'adopt'
        cache: gradle

    - name: Grant execute permission for gradlew # Shell Command 
      run: chmod +x gradlew
    - name: Build with Gradle
      run: ./gradlew build
Copy the code

Explain from the top down:

noun explain
name Set the WorkFlow name
on Set events, such as on.push.branches: [master], to trigger when the master branch pushes
jobs Declare Jobs, under Jobs abovebuildField, which is to create a Job and the name of the Job
runs-on Declare Runner, or server, to support Windows, MacOS, and Ubuntu, but specify the version
steps The statement Steps
steps.- -Represents the current Step
steps.name Name of the current Step
steps.uses Use actions in the marketplace
steps.run Executing Shell commands

With the noun explanation, we can understand the general process of the Android template above.

Android practice

We have a certain foundation, with the help of these, can do something interesting!

Imagine if we are about to release when we merge code into the Master branch. At this point, continuous integration can help us build the project, then use the generated Apk to harden, multi-channel packaging, upload backup files, and finally send success or failure messages as needed.

Again, we can make some changes in the above example to join groups that upload APK and send results to mail and spikes.

Taking my AndroidGithubAction as an example, the complete tutorial looks like this:

1. Create an Action

Select the Action bar in the Github project and we’ll see the following:

Choose custom or template mode as required. In this case, we choose Android template.

2. Modify the template

I have posted the content of the template above, please modify it:

  1. The outermost layer of thenameYou can change it.
  2. Event is triggered when the Event is changed to push.
  3. Modify the Gradle command.

Modified contents:

name: Android CI

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    
    - uses: actions/checkout@v2  # pull source code
    
    - name: set up JDK 1.8 # set the JDK
      uses: actions/setup-java@v2
      with:
        java-version: 8.0232.+ 9.1
        distribution: 'adopt'
        cache: gradle

    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
      
    - name: Build with Gradle Run the compile command
      run: ./gradlew clean && ./gradlew app:assembleDebug
Copy the code

3. Upload the APK

Just to be clear, when you’re writing a WorkFlow, there’s the Write WorkFlow panel on the left, and on the right you can search the market for the Action you want to use.

Select the Action you want to use, and the detailed documentation pops up.

Here is the Action we want to use.

With it, we can upload the compiled APK, share it across jobs, or download the resulting artifacts when the continuous integration run is over.

Introduction code:

- name: Upload Apk
  uses: actions/upload-artifact@v1
  with: 
    name: qd-info
    path: app/build/outputs/apk/debug/app-debug.apk
Copy the code

4. Upload the APK to a third-party platform

In many cases, the product needs to be uploaded to a third party platform. Take dandelion for example:

- name: Upload File to Pgyer
  run: curl -F 'file=@app/build/outputs/apk/debug/app-debug.apk' -F "_api_key=${{ secrets.API_KEY }}" -F "uKey=${{ secrets.PGYER_USER_KEY }}" -F "buildInstallType=3" https://www.pgyer.com/apiv2/app/upload
Copy the code

You can use the curl tool to curl the Github Action to delete private information.

Curl is a command line tool used to request information from a Web server.

A Guide to curl

Github recommends storing keys in Secrets and adding entry to the Github Action workflow file:

5. Acquire the builder

After the upload, we will send the compile information, version information and Commit log to the enterprise wechat, Dingding or email.

The first is to get builder information. The default environment variables are provided as follows:

The curl command has an unrecognized error:

Write the trigger in the global variable:

Get the sender
- name: Sender
  run: echo "sender=$GITHUB_ACTOR" >> $GITHUB_ENV
Copy the code

${{env.sender}}

6. Obtain the version information

I obtained the version information from the build.gradle file in the app directory by running the grep command

If you have a better way, feel free to share in the comments section

Write to global variables as well:

# step: Get the APK version number
- name: APK Version
  id: apk_version
  run: | versionCode=`grep "versionCode" app/build.gradle | awk -F " " '{print $2}'` versionName=`grep "versionName" app/build.gradle | awk -F ''\"'' '{print $2}'` echo "versionResult=$versionName.$versionCode" >> $GITHUB_ENV
Copy the code

In making the Action, if need to run multiple commands, need to be in the run: followed by a |.

7. Obtain the submission log

Git commit log git commit log git commit log

Get git log
- name: Get git log
  id: git_log
  run: | updateLog=`git log --pretty=format:"%s" -1` echo "updateLog=$updateLog" >> $GITHUB_ENVCopy the code

This command is used to obtain the logs of the most recent commit records and output them in the specified format.

8. Small robots sent to the spike swarm

The instructions for the use of the nail robot will not be introduced, directly look at the official website, the command is as follows:

# Send a message to Nail
- name: dingtalk
  run: | curl '${{ secrets.DINGDING_WEBHOOK }}' -H 'Content-Type: application/json' -d '{"msgtype": "text", "text": {" content ":" have a meal! ${{env.versionResult}} ${{env.updatelog}} ${{env.pgy_URL}"}}'Copy the code

Screenshot sent to the group after a successful build:

9. Send emails

Usually, the triggering person will receive a failure email if the compiler fails to compile. If not, we can write another Action that sends the email.

We quote other people’s open source actions here:

# Send email
- name: Send mail
  uses: dawidd6/action-send-mail@v3
  with:
    server_address: smtp.qq.com
    server_port: 465
    username: The ${{ secrets.MAILUSERNAME }}
    password: The ${{ secrets.MAILPASSWORD }}
    subject: Github Actions job result
    to: 2556536414@qq.com
    from: TeaOf 
    secure: true
    body: "Have a meal! \n Trigger person: ${{ env.sender }}\n version: ${{ env.versionResult }}\n Submission: ${{ env.updateLog }}\n Download address: ${{ secrets.PGY_URL }}"
Copy the code

And when we do that, we’re almost done.

Full code address: github.com/mCyp/Androi…

conclusion

There are also a few more common usage scenarios for Github actions for open source users.

For example, using Github Actions to automatically deploy Hexo blogs, remember when I used Github Page to create a personal blog, each time I added a post, I had to enter a string of command lines. With Github Actions, all of these are automatically implemented.

Github porfiles rely on Github actions to update their files automatically.

His Profile automatically picks up the latest personal posts and social media every three hours to display on his Profile, which is really great! I plan to do one of my own when I have time.

reference

Github Actions Tutorial and Android Continuous Integration Example