concept
GitHub Actions is GitHub’s continuous integration service that was launched in October 2018.
So what is continuous integration?
Continuous integration
Continuous Integration is also known as CI. It is a software development practice that allows teams to receive feedback and make improvements on an ongoing basis, without having to wait until later in development to find and fix defects. It is often used in agile software development. Jenkins is the continuous integration platform tool we use.
Now that I understand the concept of continuous integration, let me briefly talk about the benefits of using continuous integration:
- Improved efficiency and reduced repetitive work: some repetitive work is scripted to be performed by continuous integration services.
- Reduced manual errors: machines with pre-written scripts are much less likely to make errors than humans.
- Reduce wait time: A complete set of continuous integration services covers development, integration, testing, deployment, and so on.
- Improve product quality: Many large companies have a code review script (commonly known as gate control) after code is submitted to check whether the code is submitted in accordance with the specification, thus preventing problems from occurring at the source.
Actions
GitHub’s Actions are very lightweight and clever compared to the larger concept of continuous integration. Actions is a script for a specific function in continuous integration. Through the free combination of multiple Actions, continuous integration services of their specific functions can be realized.
Github has also created an Actions marketplace to make it easier for people to use Actions.
GitHub Actions have a few terms of their own:
- 1.
Workflow
: Continuous integration is a process that runs onceworkflow
. - 2.
Job
A:workflow
By one or morejobs
Composition means a continuous integration operation that can accomplish multiple tasks. - 3.
Step
: eachjob
By multiplestep
Constitute, step by step to complete. - 4.
Action
: eachstep
One or more commands (actions) can be executed in sequence.
Workflow document
The GitHub Actions configuration file, called the Workflow file, is stored in the. GitHub /workflows directory of the repository, as shown below:
The Workflow file is in YAML format. The file name can be arbitrary, but the file name suffix is. Yml, for example, package.yml in the figure above.
The Workflow file has many configuration fields. For details, see the official documentation. Here are some basic fields:
- 1.
name
: Workflow name. If omitted, this defaults to the file name of the current Workflow file. - 2.
on
: A condition that triggers Workflow, usually some event, such as:release
,push
,pull_request
And so on. You can refer to the detailsThe official documentation 。 - 3.
jobs
: The body of a Workflow file, representing one or more tasks to be executed.jobs.<job_id>.name
:job_id
Is the id of the task,name
It’s a description of the task.jobs.<job_id>.runs-on
:runs-on
This is a required field to run the required virtual machine environment.jobs.<job_id>.needs
:needs
Specifies the dependencies of the current task, the order in which it is run.jobs.<job_id>.steps
:steps
Specifies the running steps for each task, which can contain one or more steps.
The application of the Actions
How to publish the Flutter plugin using Action
Earlier I wrote a Guide to how to develop a Flutter Plugin and publish it. However, publishing the flutter plugin to the platform required access to the Internet and setting up a proxy for the command terminal. Therefore, publishing the flutter plugin every time was very troublesome.
By chance, I found a publish-dart-flutter-package plugin in the Action marketplace, which allows you to publish your own flutter plugin to the flutter platform with one click. The script is as follows:
name: Pub Publish plugin
on: workflow_dispatch
jobs:
publish:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v1
- name: Publish
uses: Sakebook/[email protected]
with:
credential: The ${{ secrets.CREDENTIAL_JSON }}
flutter_package: true
skip_test: true
dry_run: false
Copy the code
Of course, you can also refer to my Flutter_xUpdate, which uses this Action to publish.
Click on Run Workflow => Select the Master branch => Click on Run Workflow, as shown in the following figure:
Here we notice that we define a secrets.CREDENTIAL_JSON constant, which is our Google account authentication certificate, In the project Settings => select Secrets => New Repository Secret to create a constant with the attribute CREDENTIAL_JSON. You can find the credentials.json file in your user Home directory in the. Pub-cache folder.
The following picture shows the result of a publish action. It only takes 2 minutes to publish the Flutter plugin without using scientific web tools or configuring a proxy for the command terminal. It is very convenient!
How to package APK using Action
As an Android developer, have you ever thought github would automatically package an APK for you every time you submit code or release a version?
Wouldn’t it be nice if you didn’t have to spend a lot of time packing your APK and managing your application package?
So what should we do? The following is a Workflow script THAT I implemented. The main function is to automatically package the build script out of the APK and upload it directly to the Artifacts store when submitting code or releasing a release.
name: Android CI
on:
release:
types: [published]
push:
branches:
- master
tags:
- '2. *'
pull_request:
branches:
- master
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: set up JDK 1.8
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: release apk sign
run: | echo "to apk signature" cp $GITHUB_WORKSPACE /. Making/workflows/android. The keystore $GITHUB_WORKSPACE/app/android. The keystore sed '$a\RELEASE_STORE_FILE=./android.keystore' $GITHUB_WORKSPACE/gradle.properties -i - name: build with gradle
run: | echo "start to release build" chmod + x gradlew. / gradlew app: assembleRelease - name : upload apk
uses: actions/upload-artifact@master
if: always()
with:
name: xupdate_apk
path: The ${{ github.workspace }}/app/build/outputs/apk/release
Copy the code
Refer to my XUpdate configuration for details.
Here we can see that the trigger conditions we defined are release, push and pull_request, the trigger branch is master, and tags start with 2.*.
The whole task is mainly divided into four steps:
- 1.
Set up the JDK 1.8
: build the java1.8 environment. - 2.
release apk sign
: Configures the application signature. It is important to note that the signature configuration in this area still needs to be combinedbuild.gradleFile configuration to prepare. - 3.
build with gradle
: Compiles and builds apK. runassembleRelease
Command to release the package. - 4.
upload apk
: Upload apK toArtifacts
.
The result of the final execution is as follows:
How to use Action to counter white whoring
When I was working on open source projects, I would often encounter some anonymous minor (whopper) who would mention some issues of no value without looking at the project, and then you would kindly reply and he would disappear… It really makes people hate their teeth!
Ll: That’s right. Action can also be used to take Action against white hookers. This is also before I in the nuggets when I happened to see an article “❌ dialogue piao SAY NO!! — how to stop shameless white piao on GitHub” found.
So how did he do it? In fact, it is very simple, is set to trigger the condition is the creation of issues, during the creation of issues to query whether the creator of the repository star or fork, if the condition is met, do not do processing, otherwise it will automatically lock and close the issues.
Of course, the author also made this very sexy Action into a plugin, the address of the plugin is: github.com/marketplace… It is very simple to use.
Here’s a simple script example I used:
name: No Free usage issue checker
on:
issues:
types: [opened.reopened]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Check issue actor
uses: Fluttercandies/[email protected]
with:
token: The ${{ secrets.GITHUB_TOKEN }} # Temporary Token provided by GitHub, must be passed here, and must be this value.
forked: '--no-forked'
words: To support our project, please file the issue after you starred the repo. Thanks! 🙂
Copy the code
Here, I set the trigger condition to be the open and re-open events of issues. The setting does not force fork, but requires star. When a wild white prostitute comes and issues your project, it will trigger the following effect:
Are you surprised and excited to see the results? You think I can’t fix you because you’re a fucking whore? Ha ha, be honest with me!
The last
All see here, still don’t hurry three even support once, don’t you also want to be white whoring party?
For more information, please search my wechat official account: [My Android Open Source Journey]