别人开源项目都自动化发包了，你还在本地打包？

dora
4,063 阅读6分钟

有做过Android开源项目的是否遇到过这个困境？我也是发布release的apk安装包，为什么只有两个压缩包？死活都不出apk。

截屏2024-09-12 20.31.14.png

是不是这样？哈哈。我以前也是这样，凭什么别人的就有apk，我的就没有？

截屏2024-09-12 20.34.01.png

难道是我长得不够帅？

为什么需要这样发布apk？

那么，这样做有什么好处呢？好处当然很明显了，别人会更信任这个包的可靠性。我所说的可靠性不是你的代码稳定性好不好，而是指没有额外加入其他的黑客代码，毕竟有第三方的流程给你背书。什么？黑客代码？漏洞程序？有后门？这个功能在区块链项目中用处可能会更加突出。我举个简单的例子，如果你看不到完整的源代码，可能会有什么后果。就拿芯片来说，你买来的芯片产品，你能看到的那部分协议都很干净，但是这也只是你认为的没有问题。别人可能会在底层加入你看不到的协议。这个协议被植入了AI人工智能，可以修改你上层的源代码，植入黑客程序。然后神不知鬼不觉的，你把它装到火箭军的导弹系统中。结果可想而知，你点击按钮一发射，坐标立马被修改。这个系统变成了反向爆炸装置，最终你把自己给炸了。你说这有多恐怖！

Github Actions

好了，不扯远了。对于开源项目，你能知晓能看到产品的完整源代码，并且确认是用它打包的重要性了吧。在Github其实有一个Actions功能。

截屏2024-09-12 20.50.17.png

第四个按钮就是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则专注于软件开发过程中的自动化，包括代码集成、测试、构建和部署，以提高软件开发效率和产品质量。

代码是怎样的？

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网站上获取访问令牌，您可以按照以下步骤操作：

  1. 登录到您的GitHub账户。
  2. 点击右上角的头像，并选择“Settings”。
  3. 在左侧菜单栏中选择“Developer settings”。
  4. 在“Developer settings”页面的左侧菜单栏中选择“Personal access tokens”。
  5. 点击“Generate new token”按钮。
  6. 在“Note”字段中，填写一个描述此令牌用途的名称，以便于记忆和识别。
  7. 在“Select scopes”部分，选择需要给予该令牌的权限。
  8. 选好权限后，点击页面底部的“Generate token”按钮。
  9. 生成的令牌将会显示出来，请复制保存好该令牌。

在账号设置中，找到开发者设置。

截屏2024-09-04 21.32.06.png

点击生成，务必保管Token，只能看一次。然后使用这个token拉你Github上的代码。

接下来，在你的仓库项目中找到设置。

截屏2024-09-04 21.35.39.png

  1. 进入 GitHub 仓库的 Settings > Secrets。
  2. 创建一个新的 secret，命名为 TOKEN，并将你的访问 token 粘贴进去，注意名称要一致。

好了，然后我们使用git命令push tag，就会自动触发workflow了。

git tag 1.0.0
git push origin 1.0.0

触发条件主要有3种，push、release和workflow_dispatch。它们分别代表push时，点release时，手动点击workflow的触发按钮的时候。

巨坑

这个过程有个巨大的坑，你知道是什么吗？那就是必须是3位的版本号，我之前就是使用的2位的版本号死活都不成功。我真心无语了，我就是2位的版本号啊，硬是让我改成了3位的版本号，即中间两个点。希望你们少走弯路，一步成功，加油。

avatar
文章
阅读
粉丝