Many of us has developed open-source libraries and published it to JCenter/Bintray. For every new version we used to create a release in Github manually by going to the releases tab. For uploading to Bintray we used the bintray-gradle plugin, when a new release is created we manually run the command gradlew bintrayUpload
in terminal.
我们许多人已经开发了开源库并将其发布到JCenter / Bintray。 对于过去的每个新版本,我们过去都通过在“发行”标签中手动在Github中创建发行。 为了上传到Bintray,我们使用bintray-gradle插件,当创建新版本时,我们在终端中手动运行gradlew bintrayUpload
命令。
Quite boring work right? What if we can automate this workflow? Let’s see how we can achieve this by using Github Actions.
相当无聊的工作对吗? 如果我们可以自动化该工作流程怎么办? 让我们看看如何使用Github Actions实现这一目标。
GitHub Actions help you automate your software development workflows in the same place you store code and collaborate on pull requests and issues. You can write individual tasks, called actions, and combine them to create a custom workflow. Workflows are custom automated processes that you can set up in your repository to build, test, package, release, or deploy any code project on GitHub.
GitHub Actions可帮助您在存储代码的同一位置自动执行软件开发工作流,并就拉取请求和问题进行协作。 您可以编写单独的任务(称为操作),并将其组合以创建自定义工作流程。 工作流是自定义的自动化流程,您可以在存储库中对其进行设置,以在GitHub上构建,测试,打包,发布或部署任何代码项目。
Recently I have integrated Github Actions to my open-source library RoomInspector and automated the release and publish workflow. When a new tag is pushed to master branch, then a new release will be created automatically in Github and will be published to Bintray.
最近,我将Github Actions集成到我的开源库RoomInspector中,并自动化了发布和发布工作流程。 当将新标签推送到master分支时,新版本将在Github中自动创建,并将发布到Bintray。
You can check Room-Inspector on my github repository :
您可以在我的github存储库上检查Room-Inspector:
In this article I will explain how to automate your libraries release workflow using Github actions. At the end of this article, you will get a brief idea about Github actions and will be able to automate the your workflow.
在本文中,我将解释如何使用Github操作自动执行您的库发布工作流程。 在本文结尾,您将简要了解Github的操作,并能够自动执行您的工作流程。
开始吧… (Let’s Start…)
We have 2 flows to automate : one for GitHub release and one for Bintray publishing.
我们有2个流程可以自动化:一个流程用于GitHub版本,另一个流程用于Bintray发布。
Create a workflow .yml
file named release.yml
in your .github/workflows
directory (under projects root directory). So the final path of the file will be {projectdir}/.github/workflows/release.yml
or you can do this simply by going to the Actions tab on your Github repository and clicking on setup/new workflow.
在.github/workflows
目录(在项目根目录下)中创建一个名为release.yml
的工作流.yml
文件。 因此,文件的最终路径将是{projectdir}/.github/workflows/release.yml
或者您可以简单地通过转到Github存储库上的“操作”选项卡并单击“设置/新工作流程”来执行此操作。
I recommend you to check the workflow syntax for github actions in the official documentation.
我建议您在官方文档中检查github操作的工作流语法。
自动化Github发布 (Automating Github release)
Copy paste below lines in to the workflow file.
将以下行中的粘贴复制到工作流文件中。
name: Release
on:
push:
tags:
- 'v*'
jobs:
release:
name: Create Release
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set release name
run: echo ::set-env name=RELEASE_NAME::$(echo ${GITHUB_REF:11})
- name: Create Release
id: create_release
uses: actions/create-release@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ github.ref }}
release_name: ${{ env.RELEASE_NAME }}
body: |
What is new :
- First Change
- Second Change
draft: false
prerelease: false
Now let’s see what all these mean.
现在让我们看看所有这些意味着什么。
name
is the full name of your workflow, which will be displayed in the list of workflows under the actions tab.
name
是您的工作流程的全名,将显示在“操作”选项卡下的工作流程列表中。
on
defines on what event workflow will be triggered. In our case we want to trigger the workflow when a new tag ( with ‘v’ as prefix ) is pushed to the master branch.
on
定义将触发什么事件的工作流程。 在我们的案例中,我们希望在将新标签(以'v'作为前缀)推送到master分支时触发工作流程。
A workflow run is made up of one or more job
s. Jobs run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the jobs.<job_id>.needs
keyword. Each job must have an id to associate with the job. name
- name of the job displayed on GitHub.
工作流程运行由一个或多个job
。 默认情况下,作业并行运行。 要顺序运行作业,可以使用jobs.<job_id>.needs
关键字定义对其他作业的依赖关系。 每个作业必须具有一个ID才能与该作业关联。 name
显示在GitHub上作业的名字- 。
Each job runs in an environment specified by runs-on
. The machine can be either a GitHub-hosted runner, or a self-hosted runner.
每个作业都在runs-on
指定的环境中runs-on
。 该机器可以是GitHub托管的运行器,也可以是自托管的运行器。
A job contains a sequence of tasks called steps
. Here we defined 3 steps.
作业包含一系列称为steps
的任务。 在这里,我们定义了3个步骤。
In first step, the checkout action checks-out your repository under $GITHUB_WORKSPACE
, so the workflow can access it.
第一步, 签出操作签出$GITHUB_WORKSPACE
下的存储库,以便工作流可以访问它。
In the second step, we are creating an environment variable RELEASE_NAME
by removing the ‘v’ from the tag.
在第二步中,我们通过从标记中删除“ v”来创建环境变量RELEASE_NAME
。
Third step uses create a release action which wraps the GitHub Release API, specifically the Create a Release endpoint, to allow you to leverage GitHub Actions to create releases.
第三步使用创建发布动作 ,该动作包装了GitHub Release API (特别是创建发布端点),以允许您利用GitHub Actions创建发布。
tag_name
: The name of the tag for this releasetag_name
:此版本的标签名称release_name
: The name of the releaserelease_name
:发布的名称body
: Text describing the contents of the release. Optional, and not needed if usingbody_path
.body
:描述发布内容的文本。 可选,如果使用body_path
则body_path
。body_path
: A file with contents describing the release. Optional, and not needed if usingbody
.body_path
:一个文件,其中描述发布的内容。 可选,如果使用body
不需要。draft
:true
to create a draft (unpublished) release,false
to create a published one. Default:false
draft
:true
,则创建草稿(未发布)版本;如果为false
,则创建已发布的版本。 默认值:false
prerelease
:true
to identify the release as a prerelease.false
to identify the release as a full release. Defaultfalse
prerelease
:将发行版标识为预发行版时为true
。false
将发行版标识为完整发行版,false
。 默认为false
We have successfully created our workflow for automating github release . Now, for each tag that you are pushing, a new release will be created in Github automatically. Will test everything together after automating the Bintray upload flow.
我们已经成功创建了用于自动化github发布的工作流程。 现在,对于您要推送的每个标签,将在Github中自动创建一个新版本。 自动执行Bintray上传流程后,将一起测试所有内容。
自动化Bintray上传 (Automating Bintray Upload)
I am assuming that you already have a bintray account and configured the gradle client. If not, please create and configure Bintray account. Also configure the build.gradle
files with the code as below.
我假设您已经有一个Bintray帐户并配置了gradle客户端。 如果没有,请创建并配置Bintray帐户。 还使用以下代码配置build.gradle
文件。
dependencies {
//...
classpath "com.jfrog.bintray.gradle:gradle-bintray-plugin:1.8.4"
classpath "com.github.dcendents:android-maven-gradle-plugin:2.1"
}
ext {
bintrayRepo = 'RoomInspector'
bintrayName = 'com.ktvipin.roominspector'
publishedGroupId = 'com.ktvipin'
libraryName = 'library'
artifact = 'roominspector'
libraryDescription = 'An in-app database inspector for Room databases.'
libraryVersion = '1.0.2'
siteUrl = 'https://github.com/ktvipin27/RoomInspector'
gitUrl = 'https://github.com/ktvipin27/RoomInspector.git'
githubRepository= 'ktvipin27/RoomInspector'
developerId = 'ktvipin27'
developerName = 'Vipin KT'
developerEmail = 'ktvipin27@gmail.com'
licenseName = 'The Apache Software License, Version 2.0'
licenseUrl = 'http://www.apache.org/licenses/LICENSE-2.0.txt'
allLicenses = ["Apache-2.0"]
}
apply from: 'https://raw.githubusercontent.com/ktvipin27/RoomInspector/master/library/publish.gradle'
Open the publish.gradle
, you can see that we are accessing 2 environment variables from the system — bintrayUser and bintrayApiKey. If you are accessing these values from properties file, please change to environment variables.
打开publish.gradle
,您可以看到我们正在从系统访问2个环境变量— bintrayUser和bintrayApiKey 。 如果要从属性文件访问这些值,请更改为环境变量。
bintray {
user = System.getenv("bintrayUser")
key = System.getenv("bintrayApiKey")
//...
}
Now go to Settings tab on your Github repo and click on the Secrets section. Add 2 secrets named BINTRAY_API_KEY & BINTRAY_USER .These keys will contain your Bintray api key and user name respectively, you can copy the values from your Bintray profile page. We will use these secrets for creating the above mentioned environment variables.
现在转到Github存储库上的“ 设置”标签,然后单击“ 秘密”部分。 添加两个名为BINTRAY_API_KEY和BINTRAY_USER的秘密。 这些密钥将分别包含您的Bintray api密钥和用户名,您可以从Bintray配置文件页面复制值。 我们将使用这些秘密来创建上述环境变量。
As I mentioned earlier in this article, a workflow can have multiple jobs. So rather than creating a separate workflow file, will add bintray upload as a job in to the same workflow file. You can even add this as steps in the same job without creating a new job.
正如我在本文前面提到的,一个工作流可以有多个作业。 因此,与其创建一个单独的工作流文件,不如将bintray上传作为一项工作添加到同一工作流文件中。 您甚至可以将其作为步骤添加到同一作业中,而无需创建新作业。
publish:
name: Publish Build
runs-on: ubuntu-latest
needs: release
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Configure JDK
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Publish library
env:
bintrayUser: ${{ secrets.BINTRAY_USER }}
bintrayApiKey: ${{ secrets.BINTRAY_API_KEY }}
run: ./gradlew bintrayUpload
The line needs: release
adds a dependency on previous job to make the jobs run in sequential order.
该行needs: release
添加对先前作业的依赖关系,以使作业按顺序运行。
This job has 3 steps.
这项工作包含3个步骤。
In first step, same as previous job, check-out the code.
第一步,与上一个作业相同,签出代码。
Second step uses setup-java action , which will install Java.
第二步使用setup-java action ,它将安装Java。
In the Publish library step, we will initialize the environment variables from the secrets which we have created earlier. And finally will run the bintrayUpload
command, which will upload library to Bintray.
在发布库步骤中,我们将从先前创建的机密中初始化环境变量。 最后将运行bintrayUpload
命令,该命令会将库上传到Bintray。
The final release.yml
after combining both jobs will look like :
合并两个作业后的最终release.yml
如下所示:
name: Release
on:
push:
tags:
- 'v*'
jobs:
release:
name: Create Release
runs-on: macos-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set release name
run: echo ::set-env name=RELEASE_NAME::$(echo ${GITHUB_REF:11})
- name: Create release
id: create_release
uses: actions/create-release@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ github.ref }}
release_name: ${{ env.RELEASE_NAME }}
draft: false
prerelease: false
publish:
name: Publish Build
runs-on: ubuntu-latest
needs: release
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Configure JDK
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Publish library
env:
bintrayUser: ${{ secrets.BINTRAY_USER }}
bintrayApiKey: ${{ secrets.BINTRAY_API_KEY }}
run: ./gradlew bintrayUpload
Done.! Now push the workflow file and will see how it works.
完成了! 现在推送工作流程文件,并查看其工作方式。
测试中 (Testing)
Go to Actions tab on your github repository, the workflow which you have created will be displayed there.
转到github存储库上的“ 操作”选项卡,您创建的工作流程将显示在此处。
2. Now create a tag and push it.
2.现在创建一个标签并推送它。
3. Go to Actions tab again, you can see that the workflow is started executing.
3.再次转到“ 操作”选项卡,您可以看到工作流已开始执行。
4. Once the job completes , go to releases, the new release will be added there.
4.作业完成后,转到发行版,新发行版将添加到此处。
5. Go to your bintray account and navigate to your libraries page, you can see that your new version will be listed under the versions section.
5.转到您的Bintray帐户并导航到“库”页面,您会看到新版本将在“版本”部分下列出。
结语 (Wrapping up)
Here I have shown how to automate Android library release & publish using Github actions. For future releases, you don’t need to do anything manually. Once your new update is ready, create a tag and push it, a new version of the library will be created in Github and will be automatically published to the Bintray. Don’t forget to update library version and changelog before creating the tag.
在这里,我展示了如何使用Github操作自动化Android库的发布和发布。 对于将来的版本,您无需手动执行任何操作。 一旦您的新更新准备就绪,创建一个标签并推送它,该库的新版本将在Github中创建并自动发布到Bintray。 创建标记之前,请不要忘记更新库版本和changelog。
The explained workflows is simple, which makes your library release faster. You can add more jobs to make it even better ie; for generating tags, code analysis, test execution, building apk etc. You can find more cool actions on Github marketplace.
解释的工作流程很简单,这使您的库发布更快。 您可以添加更多工作来使它更好,即; 用于生成标签,代码分析, 测试执行,构建apk等。您可以在Github市场上找到更多有趣的动作。
翻译自: https://proandroiddev.com/automating-android-library-release-using-github-actions-c783e44ea216
所有评论(0)