有做过Android开源项目的是否遇到过这个困境?我也是发布release的apk安装包,为什么只有两个压缩包?死活都不出apk。
是不是这样?哈哈。我以前也是这样,凭什么别人的就有apk,我的就没有?
难道是我长得不够帅?
为什么需要这样发布apk?
那么,这样做有什么好处呢?好处当然很明显了,别人会更信任这个包的可靠性。我所说的可靠性不是你的代码稳定性好不好,而是指没有额外加入其他的黑客代码,毕竟有第三方的流程给你背书。什么?黑客代码?漏洞程序?有后门?这个功能在区块链项目中用处可能会更加突出。我举个简单的例子,如果你看不到完整的源代码,可能会有什么后果。就拿芯片来说,你买来的芯片产品,你能看到的那部分协议都很干净,但是这也只是你认为的没有问题。别人可能会在底层加入你看不到的协议。这个协议被植入了AI人工智能,可以修改你上层的源代码,植入黑客程序。然后神不知鬼不觉的,你把它装到火箭军的导弹系统中。结果可想而知,你点击按钮一发射,坐标立马被修改。这个系统变成了反向爆炸装置,最终你把自己给炸了。你说这有多恐怖!
Github Actions
好了,不扯远了。对于开源项目,你能知晓能看到产品的完整源代码,并且确认是用它打包的重要性了吧。在Github其实有一个Actions功能。
第四个按钮就是Actions工作流(Workflow)功能了,我们来和CI/CD一起看下。
Workflow和CI/CD(持续集成/持续部署)的主要区别在于它们的功能和目的。
- Workflow主要指的是业务过程的部分或整体在计算机应用环境下的自动化,它是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。Workflow是对工作流及其业务规则的计算机化表示,旨在协调工作流执行过程之间以及群体成员之间的信息交互。Workflow管理系统(WfMS)通过计算机技术支持定义、执行和管理工作流程,协调工作流执行过程之间以及群体成员之间的信息交互。
- CI/CD则是一种软件开发实践,包括持续集成(Continuous Integration)和持续部署(Continuous Deployment),强调从代码签入、测试、构建到部署的自动化流程。CI/CD流程通过自动化工具和技术,如Jenkins、Argo、Tekton等,实现软件的快速、规模交付。这一过程包括代码的自动编译、测试、以及最终部署到生产环境,旨在提高软件开发的效率和质量,减少人为错误和延迟。
简而言之,Workflow更侧重于业务流程的自动化管理,而CI/CD则专注于软件开发过程中的自动化,包括代码集成、测试、构建和部署,以提高软件开发效率和产品质量。
代码是怎样的?
yml 代码解读复制代码name: Android CI Build
on:
# workflow_dispatch:
push:
tags:
- '*' # 当push标签时触发
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Set up output
id: vars
run: |
echo "short_ref=${GITHUB_REF#refs/*/}" >> $GITHUB_OUTPUT
echo "tag=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT
- name: Checkout
id: check
uses: actions/checkout@v4
- name: Set up JDK
uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
- name: Set up Android SDK
uses: android-actions/setup-android@v3
- name: Setup Gradle
uses: gradle/gradle-build-action@v3
- name: Build App
run: |
./gradlew app:assembleRelease
- name: Create Github Release
if: github.repository == 'dora4/DoraCacheSample'
uses: taiki-e/create-gh-release-action@v1
env:
GITHUB_TOKEN: ${{ secrets.TOKEN }}
- name: Create Release
uses: softprops/action-gh-release@v2
if: startsWith(github.ref, 'refs/tags/')
with:
files: 'app/build/outputs/apk/release/*.apk'
使用流程解析
这个yml文件存放的目录是项目根目录下的.github/workflows目录中,需要注意这里有个TOKEN,它是你的GitHub的访问令牌。
要在GitHub网站上获取访问令牌,您可以按照以下步骤操作:
- 登录到您的GitHub账户。
- 点击右上角的头像,并选择“Settings”。
- 在左侧菜单栏中选择“Developer settings”。
- 在“Developer settings”页面的左侧菜单栏中选择“Personal access tokens”。
- 点击“Generate new token”按钮。
- 在“Note”字段中,填写一个描述此令牌用途的名称,以便于记忆和识别。
- 在“Select scopes”部分,选择需要给予该令牌的权限。
- 选好权限后,点击页面底部的“Generate token”按钮。
- 生成的令牌将会显示出来,请复制保存好该令牌。
在账号设置中,找到开发者设置。
点击生成,务必保管Token,只能看一次。然后使用这个token拉你Github上的代码。
接下来,在你的仓库项目中找到设置。
- 进入 GitHub 仓库的
Settings > Secrets
。 - 创建一个新的 secret,命名为
TOKEN
,并将你的访问 token 粘贴进去,注意名称要一致。
好了,然后我们使用git命令push tag,就会自动触发workflow了。
shell代码解读复制代码git tag 1.0.0 git push origin 1.0.0
触发条件主要有3种,push、release和workflow_dispatch。它们分别代表push时,点release时,手动点击workflow的触发按钮的时候。
巨坑
这个过程有个巨大的坑,你知道是什么吗?那就是必须是3位的版本号,我之前就是使用的2位的版本号死活都不成功。我真心无语了,我就是2位的版本号啊,硬是让我改成了3位的版本号,即中间两个点。希望你们少走弯路,一步成功,加油。
评论记录:
回复评论: