fix(ci): fix release workflow #13

luke · 2025-05-30T20:38:27Z

luke commented

2025-05-30 20:38:27 +00:00

Okay, here's a breakdown of the changes introduced by the provided Git diff:

Overall Goal:

The primary goal of this change is to automate the release process using a scheduled trigger (cron) and pre-existing tags, decoupling it from direct push events and leveraging a separate job to generate the release tag. This makes the release process more controlled and predictable.

Key Changes:

Trigger Mechanism Changed:
- The trigger for the workflow has been altered from push events on master or main branches to a scheduled cron job.
- on: section now contains only workflow_dispatch and schedule:
```
on:
  workflow_dispatch:
  schedule:
    - cron: '0 9 * * 0'
```
- The cron expression '0 9 * * 0' means the workflow will run every Sunday at 9:00 AM UTC.
Tag Creation Job Introduced:
- A new job named tag has been added. This job is responsible for creating the release tag.
- It reuses a workflow from https://git.tainton.uk/actions/gha-workflows/.gitea/workflows/release-with-tag.yaml@main. This implies that workflow handles the logic for determining the tag name and creating the tag in the repository.
```
tag:
  name: Tag release
  uses: https://git.tainton.uk/actions/gha-workflows/.gitea/workflows/release-with-tag.yaml@main
```
create_release Job Modified:
- The create_release job now depends on the tag job (needs: tag).
- It now uses a different reusable workflow: https://git.tainton.uk/actions/gha-workflows/.gitea/workflows/create-release-preexisting-tag.yaml@main. This new workflow is designed to create a release based on a pre-existing tag.
- It receives the tag name and changelog from the tag job outputs:
```
create_release:
  name: Create Release
  needs: tag
  uses: https://git.tainton.uk/actions/gha-workflows/.gitea/workflows/create-release-preexisting-tag.yaml@main
  with:
    tag: ${{ needs.tag.outputs.tag_name }}
    body: ${{ needs.tag.outputs.changelog }}
  secrets:
    ACTIONS_TOKEN: ${{ secrets.ACTIONS_TOKEN }}
```
print_release Job Removed:
- The print_release job has been removed. This job simply echoed the release name and was likely used for debugging or informational purposes. It's not essential to the release process itself.

create_docker Job Updated:

The create_docker job now depends on both tag and create_release jobs.
The ref in the actions/checkout step is updated to use needs.tag.outputs.tag_name to checkout the tag created in the tag job.

The tags value in the docker/metadata-action step is also updated to use needs.tag.outputs.tag_name.

create_docker:
  name: Publish Docker Images
  runs-on: ubuntu-latest
  needs: [tag, create_release]
  steps:
    # ... other steps ...
    - name: Checkout code
      uses: actions/checkout@v4.2.2
      with:
        fetch-depth: 0
        ref: ${{ needs.tag.outputs.tag_name }}
    # ... other steps ...
    - name: Extract Docker metadata
      id: meta
      uses: docker/metadata-action@v5
      with:
        tags: type=semver,pattern=v{{version}},value=${{ needs.tag.outputs.tag_name }}
        images: |
          ghcr.io/${{ vars.GHCR_USERNAME }}/${{ steps.split.outputs.repo }}
          ${{ vars.PACKAGES_REGISTRY_URL }}/${{ gitea.repository }}

Impact and Reasoning:

Scheduled Releases: The shift to a cron schedule ensures releases happen regularly and predictably, rather than being tied directly to code commits.
Decoupled Tag Creation: The tag job isolates the tag creation logic. This could involve automated version bumping based on commit messages or other criteria (details are in the reusable workflow it uses). This separation of concerns makes the overall workflow more maintainable.
Using Pre-existing Tags for Release: The create_release-preexisting-tag.yaml workflow suggests that the release creation is now based on the tag created by the tag job. This is useful because the tag might contain metadata like the version number, which is then used to create the release.
Docker Image Publishing Based on Tag: The create_docker job ensures that Docker images are built and published based on the release tag, maintaining consistency between the release and the published artifacts.

In summary, the changes represent a move towards a more automated and structured release process driven by a schedule and a separate tag creation step.

Okay, here's a breakdown of the changes introduced by the provided Git diff: **Overall Goal:** The primary goal of this change is to automate the release process using a scheduled trigger (cron) and pre-existing tags, decoupling it from direct `push` events and leveraging a separate job to generate the release tag. This makes the release process more controlled and predictable. **Key Changes:** 1. **Trigger Mechanism Changed:** * The trigger for the workflow has been altered from `push` events on `master` or `main` branches to a scheduled `cron` job. * `on:` section now contains only `workflow_dispatch` and `schedule`: ```yaml on: workflow_dispatch: schedule: - cron: '0 9 * * 0' ``` * The `cron` expression `'0 9 * * 0'` means the workflow will run every Sunday at 9:00 AM UTC. 2. **Tag Creation Job Introduced:** * A new job named `tag` has been added. This job is responsible for creating the release tag. * It reuses a workflow from `https://git.tainton.uk/actions/gha-workflows/.gitea/workflows/release-with-tag.yaml@main`. This implies that workflow handles the logic for determining the tag name and creating the tag in the repository. ```yaml tag: name: Tag release uses: https://git.tainton.uk/actions/gha-workflows/.gitea/workflows/release-with-tag.yaml@main ``` 3. **`create_release` Job Modified:** * The `create_release` job now depends on the `tag` job (`needs: tag`). * It now uses a different reusable workflow: `https://git.tainton.uk/actions/gha-workflows/.gitea/workflows/create-release-preexisting-tag.yaml@main`. This new workflow is designed to create a release based on a pre-existing tag. * It receives the tag name and changelog from the `tag` job outputs: ```yaml create_release: name: Create Release needs: tag uses: https://git.tainton.uk/actions/gha-workflows/.gitea/workflows/create-release-preexisting-tag.yaml@main with: tag: ${{ needs.tag.outputs.tag_name }} body: ${{ needs.tag.outputs.changelog }} secrets: ACTIONS_TOKEN: ${{ secrets.ACTIONS_TOKEN }} ``` 4. **`print_release` Job Removed:** * The `print_release` job has been removed. This job simply echoed the release name and was likely used for debugging or informational purposes. It's not essential to the release process itself. 5. **`create_docker` Job Updated:** * The `create_docker` job now depends on both `tag` and `create_release` jobs. * The `ref` in the `actions/checkout` step is updated to use `needs.tag.outputs.tag_name` to checkout the tag created in the `tag` job. * The `tags` value in the `docker/metadata-action` step is also updated to use `needs.tag.outputs.tag_name`. ```yaml create_docker: name: Publish Docker Images runs-on: ubuntu-latest needs: [tag, create_release] steps: # ... other steps ... - name: Checkout code uses: actions/checkout@v4.2.2 with: fetch-depth: 0 ref: ${{ needs.tag.outputs.tag_name }} # ... other steps ... - name: Extract Docker metadata id: meta uses: docker/metadata-action@v5 with: tags: type=semver,pattern=v{{version}},value=${{ needs.tag.outputs.tag_name }} images: | ghcr.io/${{ vars.GHCR_USERNAME }}/${{ steps.split.outputs.repo }} ${{ vars.PACKAGES_REGISTRY_URL }}/${{ gitea.repository }} ``` **Impact and Reasoning:** * **Scheduled Releases:** The shift to a cron schedule ensures releases happen regularly and predictably, rather than being tied directly to code commits. * **Decoupled Tag Creation:** The `tag` job isolates the tag creation logic. This could involve automated version bumping based on commit messages or other criteria (details are in the reusable workflow it uses). This separation of concerns makes the overall workflow more maintainable. * **Using Pre-existing Tags for Release:** The `create_release-preexisting-tag.yaml` workflow suggests that the release creation is now based on the tag created by the `tag` job. This is useful because the tag might contain metadata like the version number, which is then used to create the release. * **Docker Image Publishing Based on Tag:** The `create_docker` job ensures that Docker images are built and published based on the release tag, maintaining consistency between the release and the published artifacts. In summary, the changes represent a move towards a more automated and structured release process driven by a schedule and a separate tag creation step.

luke added 1 commit 2025-05-30 20:38:28 +00:00

fix(ci): fix release workflow

Validate PR Title / validate (pull_request) Successful in 6s

Details

CI / ci (pull_request) Successful in 1m16s

Details

1f63919817

luke added 1 commit 2025-05-30 20:40:36 +00:00

fix(ci): auto-release on push to main

Validate PR Title / validate (pull_request) Successful in 4s

Details

CI / ci (pull_request) Successful in 51s

Details

ffc5e90d52

ai-review-bot commented

2025-05-30 20:40:41 +00:00

Decision: Accept
Change Score: 9/10

Okay, I've reviewed the changes to the release workflow. The changes look good overall, moving to a tag based release system is a great idea.

Here's a breakdown:

Good: The workflow now uses a dedicated job (tag) to create the release tag, which is more organized.
Good: Using create-release-preexisting-tag.yaml is correct given the new tag creation process.
Good: The publish job (now create_docker) correctly waits for both the tag creation and the release creation before building the docker images.
Good: The ref in the checkout action and the value in the docker metadata action are correctly updated to use the tag name.

A few minor things:

The workflow trigger now only includes main. This is likely intentional, but make sure this is correct.
There is a commented out schedule section. While commented out code is harmless, consider removing it to reduce confusion.

I am happy to accept this, but keep the comments in mind.

**Decision: Accept** **Change Score: 9/10** Okay, I've reviewed the changes to the release workflow. The changes look good overall, moving to a tag based release system is a great idea. Here's a breakdown: * Good: The workflow now uses a dedicated job (`tag`) to create the release tag, which is more organized. * Good: Using `create-release-preexisting-tag.yaml` is correct given the new tag creation process. * Good: The `publish` job (now `create_docker`) correctly waits for both the tag creation and the release creation before building the docker images. * Good: The `ref` in the checkout action and the `value` in the docker metadata action are correctly updated to use the tag name. A few minor things: 1. The workflow trigger now only includes `main`. This is likely intentional, but make sure this is correct. 2. There is a commented out `schedule` section. While commented out code is harmless, consider removing it to reduce confusion. I am happy to accept this, but keep the comments in mind.

luke merged commit 622eedb7c0 into main

2025-05-30 20:42:27 +00:00

luke deleted branch fix/ci

2025-05-30 20:42:27 +00:00

luke referenced this issue from a commit

2025-05-30 20:42:27 +00:00

fix(ci): fix release workflow (#13)

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: repos/docker-dnsmasq#13