refactor(ci): refactor into two workflow files

[dabao1955]

No description provided.

[MakinoharaShoko]

修改后的 ci 能够在 release 时获取到 tag 吗？手动触发时，${{ github.ref }} 会获取到怎样的信息？

[dabao1955]

修改后的 ci 能够在 release 时获取到 tag 吗？手动触发时，${{ github.ref }} 会获取到怎样的信息？

理论上来说手动触发时 ${{ github.ref }} 应该为空，push时应该能获取到分支版本

[dabao1955]

修改后的 ci 能够在 release 时获取到 tag 吗？手动触发时，${{ github.ref }} 会获取到怎样的信息？

理论上来说手动触发时 ${{ github.ref }} 应该为空，push时应该能获取到分支版本

实际试了一下手动触发时为refs/heads/main，push带tag推送为refs/tags/x.x.x

[MakinoharaShoko]

近期将会再次审阅，请等待我们做更多的验证保证 ci 有效

[dabao1955]

如果单个ci不行的话拆成两个ci也行

[MakinoharaShoko]

来自 o1 的 review:

您已经成功地将三个 CI 文件合并为一个，但在合并过程中存在一些问题和遗漏，需要修正：

1. 缺少压缩步骤：在原来的 Release WebGAL Terre 工作流中，每个构建任务在完成构建后都有一个 Compress 步骤，用于将构建结果压缩为 ZIP 文件。例如：

   - name: Compress
     run: 7z a -tzip WebGAL_Terre_Linux.zip release/*

   在修改后的工作流中，这些压缩步骤缺失了。这将导致在发布步骤中引用的压缩文件不存在，因为它们从未创建。

2. 上传制品的路径不一致：在原来的工作流中，上传的制品是压缩后的 ZIP 文件，而在修改后的工作流中，上传的是未压缩的 release 目录。这会导致发布步骤无法找到预期的制品。

3. 上传制品的条件限制：在修改后的工作流中，您在上传制品的步骤添加了条件 if: github.event_name == 'push'，这意味着在 pull_request 事件中将不会上传制品。然而，在原来的 Build Check 工作流中，制品是在 pull_request 事件中上传的。如果您希望在 PR 中也能获取制品供测试或审核，应该移除这个条件或调整为合适的逻辑。

4. 发布步骤的触发条件：在修改后的工作流中，发布步骤的条件为：

   if: github.event_name == 'workflow_dispatch' || github.event_name == 'push' && startsWith(github.ref, 'refs/tags/')

   这个条件基本正确，但需要确保逻辑运算符的优先级。为了避免歧义，建议使用括号：

   if: github.event_name == 'workflow_dispatch' || (github.event_name == 'push' && startsWith(github.ref, 'refs/tags/'))

5. 制品名称和路径的一致性：在发布步骤中，上传制品时引用了特定的文件名，例如：

   asset_path: WebGAL_Terre_Linux/WebGAL_Terre_Linux.zip

   如果压缩步骤缺失，或者上传的制品名称与这里引用的不一致，发布将失败。

建议的解决方案：

• 添加压缩步骤：在每个构建任务中，构建完成后添加压缩步骤，并确保压缩后的文件名与发布步骤中引用的名称一致。

  - name: Compress
    run: 7z a -tzip WebGAL_Terre_Linux.zip release/*

• 调整上传制品的路径：在上传制品的步骤中，确保上传的是压缩后的 ZIP 文件，而不是整个目录。

  - name: Upload Artifact
    if: github.event_name == 'push'
    uses: actions/upload-artifact@v4
    with:
      name: WebGAL_Terre_Linux
      path: WebGAL_Terre_Linux.zip

• 考虑在 PR 中上传制品：如果您希望在 pull_request 事件中也上传制品，便于测试和审核，您可以调整条件或移除条件，使制品在所有事件中都被上传。

• 确保条件逻辑正确：在条件语句中使用括号来明确逻辑运算符的优先级，避免意外的逻辑错误。

通过解决上述问题，您将能够成功地将三个 CI 文件合并为一个，同时确保所有功能正常运行。

[MakinoharaShoko]

已收到你的更新，我们将会在下一次发版的时候测试 CI 能否正常运行。下一次发版可能在 1-2 周后。

[MakinoharaShoko]

@dabao1955 能否尝试 fork 一份 WebGAL Terre，然后完成一个简单的 PR-Merge-发布（打 Tag）流程，以便我们验证该流程是否能够符合我们的目标？

[dabao1955]

@dabao1955 能否尝试 fork 一份 WebGAL Terre，然后完成一个简单的 PR-Merge-发布（打 Tag）流程，以便我们验证该流程是否能够符合我们的目标？

  test:
    name: test
    runs-on: ubuntu-latest
    if: github.event_name == 'workflow_dispatch' || (github.event_name == 'push' && startsWith(github.ref, 'refs/tags/'))
    steps:
      - run: echo  ${{ github.ref }}

我测试了一下，发现提交到main分支后提示the job was skipped，可能拆成一个构建一个发布会更合适。

[MakinoharaShoko]

@dabao1955 请解决一下冲突

[MakinoharaShoko]

release.yml 删除了所有构建的脚本，那么现在这个 workflow 有前置条件吗，构建产物是如何获取的？
并且，我希望能够在你的 fork 上看到一个简单的 PR-Merge-发布（打 Tag）流程，并看到发布的 Release，以确定该工作流可以完全走通。

[dabao1955]

release.yml 删除了所有构建的脚本，那么现在这个 workflow 有前置条件吗，构建产物是如何获取的？
并且，我希望能够在你的 fork 上看到一个简单的 PR-Merge-发布（打 Tag）流程，并看到发布的 Release，以确定该工作流可以完全走通。

关于您的疑问，这是build-terre.yml的开头:

name: Build WebGAL Terre

on:
  workflow_dispatch:
  push:
    branches:
      - main
  pull_request:
    types:
      - opened
      - reopened
      - synchronize

这是release.yml的开头:

name: Release WebGAL Terre

on:
  workflow_dispatch:
  push:
    tags:
      - '*.*'
jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    needs: ['build-linux','build-arm64','build-mac','build-windows','build-windows-nsis']
    steps:

实际上版本号发布的构建流程是这样子的:

请忽略掉test那个是测试用的

[MakinoharaShoko]

下载的压缩包有问题 @dabao1955

[dabao1955]

下载的压缩包有问题 @dabao1955

已修复，请检查@MakinoharaShoko