Okay, I will review the provided Git diff and explain the proposed changes. Here's a breakdown:
**File:** `.gitea/workflows/ci.yml`
This file defines the CI (Continuous Integration) workflow for the Gitea repository. The workflow is triggered on certain events (likely pushes and pull requests).
**Changes:**
1. **Hadolint Action:**
* The change introduces a `name` field to the `hadolint-action` step, renaming it to "Run Hadolint". This improves the readability of the workflow execution logs.
2. **SonarQube Scan (Commented Out):**
* The SonarQube Scan action is commented out. This means that the SonarQube static analysis will no longer be performed as part of the CI workflow *for now*. The environment variables `SONAR_HOST_URL` and `SONAR_TOKEN` were used to authenticate with SonarQube and are now also commented out.
3. **Snyk SAST Scan:**
* A new step called "Snyk SAST Scan" is added. This step uses the `snyk/actions/python@master` action to perform static application security testing (SAST) using Snyk.
* It uses the `SNYK_TOKEN` secret to authenticate with Snyk.
* The `args` parameter is set to `snyk code test --all-projects --exclude=.archive`. This tells Snyk to scan all projects in the repository for security vulnerabilities and to exclude the `.archive` directory from the scan.
**Summary:**
The primary changes are the addition of a Snyk SAST scan and the temporary removal of the SonarQube scan from the CI workflow. Hadolint was updated with a name to provide clarity. The Snyk scan performs static analysis to identify potential security vulnerabilities directly in the codebase. The SonarQube scan is commented out, possibly for temporary reasons such as configuration issues, cost optimization, or replacement by the Snyk SAST scan.
Reviewed-on: #15
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.
Reviewed-on: #13
