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
The proposed change updates the `dnsmasq` version in the Dockerfile.
Specifically, the line:
```diff
-RUN apk --no-cache add dnsmasq=2.90-r3
+RUN apk --no-cache add dnsmasq=2.91-r0
```
is modified. This line installs the `dnsmasq` package using Alpine Package Keeper (apk). The change updates the version of `dnsmasq` from `2.90-r3` to `2.91-r0`. This likely incorporates bug fixes, security updates, or new features present in the newer version.
Reviewed-on: #14
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
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| alpine | final | minor | `3.21` -> `3.22` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MC4zMy45IiwidXBkYXRlZEluVmVyIjoiNDAuMzMuOSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsidHlwZS9kZXBlbmRlbmNpZXMiXX0=-->
Reviewed-on: #12
Reviewed-by: Luke Tainton <luke@tainton.uk>
Co-authored-by: Renovate [BOT] <renovate-bot@git.tainton.uk>
Co-committed-by: Renovate [BOT] <renovate-bot@git.tainton.uk>
In this commit I've done the following. These changes have been tested and confirmed to work.
- Updated Alpine to 3.14 and Webproc to 0.4.0
- The WEBPROC variable names have changed due to a renaming of the downloadable assets on GitHub
- The Webproc flags have changed slightly due to an upstream syntax change
