Change to monitoring.yaml (#595)

This harmonizes us with Serpent OS. We can now use some of their tooling
and we can share monitoring.yaml files.

docs/packaging/monitoring.yml.md → docs/packaging/monitoring.yaml.md

@@ -1,25 +1,25 @@
 ---
 title: Monitoring YAML
-summary: The purpose and format of monitoring.yml
+summary: The purpose and format of monitoring.yaml
 ---
 
-# `monitoring.yml`
+# `monitoring.yaml`
 
 :::important
 
-A `monitoring.yml` file is strongly suggested, but not yet required for Solus packages.
+A `monitoring.yaml` file is strongly suggested, but not yet required for Solus packages.
 
 :::
 
-A `monitoring.yml` file is included in the Packages repository directory for every Solus package to enable automatic scanning for new releases and security advisories.
+A `monitoring.yaml` file is included in the Packages repository directory for every Solus package to enable automatic scanning for new releases and security advisories.
 
 Checking for new releases is done by mapping the Solus package to an [Anitya](https://github.com/fedora-infra/anitya) ID. _Anitya_ is a Red Hat project, part of [release-monitoring.org](https://release-monitoring.org/)
 
 Checking for security advisories ([CVEs](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures)), is done by mapping the Solus package to a _Common Platform Enumeration Name_ ([CPE](https://nvd.nist.gov/products/cpe)) from the National Vulnerability Database.
 
-## Adding monitoring.yml to an existing package
+## Adding monitoring.yaml to an existing package
 
-To add a `monitoring.yml` file to an existing package you can use the following `go-task` command to add a template file, starting from within the directory containing the `package.yml` for a given package:
+To add a `monitoring.yaml` file to an existing package you can use the following `go-task` command to add a template file, starting from within the directory containing the `package.yml` for a given package:
 
 ```bash
 go-task add-monitoring
@@ -41,19 +41,19 @@ You must, at minimum, fill out `id` and check if the package has an RSS feed and
 
 ## systemd as an example
 
-Let's look at the `monitoring.yml` file for `systemd` as an example.
+Let's look at the `monitoring.yaml` file for `systemd` as an example.
 
 The `systemd` directory in the Packages repository looks like this:
 
 ```text
 systemd
-├── monitoring.yml
+├── monitoring.yaml
 ├── package.yml
 ├── pspec_x86_64.xml
 └── *lots of other files we can ignore*
 ```
 
-The `monitoring.yml` looks like this:
+The `monitoring.yaml` looks like this:
 
 ```yaml
 releases:

docs/packaging/packaging-changes.md

@@ -11,6 +11,15 @@ This page is meant to serve as a changelog of sorts for the Solus packaging envi
 - This list is not exhaustive
 - This list is in _reverse chronological order_ (newest first)
 
+## 2025
+
+### January
+
+#### `monitoring.yml` changed to `monitoring.yaml`
+
+- The file extension used by `monitoring.yml` was changed to `monitoring.yaml`
+- This allows us to use some Serpent OS tooling and share the `monitoring.yaml` files
+
 ## 2024
 
 ### December
@@ -19,12 +28,12 @@ This page is meant to serve as a changelog of sorts for the Solus packaging envi
 
 - To use it, run `go-task updatecheck`
 - Makes use of the `ent` tool. See https://github.com/serpent-os/ent
-- Only checks packages with `monitoring.yml` files
+- Only checks packages with `monitoring.yaml` files
 - `ent` has been added to the packaging requirements in [Prepare for Packaging](docs/packaging/prepare-for-packaging.md)
 
-#### Mandatory rss field in monitoring.yml
+#### Mandatory rss field in monitoring.yaml
 
-- The `rss` field is now mandatory in monitoring.yml files. See the updated [monitoring.yml page](docs/packaging/monitoring.yml.md)
+- The `rss` field is now mandatory in monitoring.yaml files. See the updated [monitoring.yaml page](docs/packaging/monitoring.yaml.md)
 
 ### November
 
@@ -43,9 +52,9 @@ This page is meant to serve as a changelog of sorts for the Solus packaging envi
 
 ### October
 
-#### Add check for monitoring.yml
+#### Add check for monitoring.yaml
 
-- Commits are now checked for `monitoring.yml` files and their inclusion is strongly recommended. See [monitoring.yml page](docs/packaging/monitoring.yml.md)
+- Commits are now checked for `monitoring.yaml` files and their inclusion is strongly recommended. See [monitoring.yaml page](docs/packaging/monitoring.yaml.md)
 
 #### Add check for included static libraries
 
@@ -94,9 +103,9 @@ This page is meant to serve as a changelog of sorts for the Solus packaging envi
 
 ### February
 
-#### Begin adding `monitoring.yml` to packages
+#### Begin adding `monitoring.yaml` to packages
 
-- A new per-package file was introduced: `monitoring.yml`. Used to monitor packages for releases and security advisories; see [monitoring.yml](docs/packaging/monitoring.yml.md).
+- A new per-package file was introduced: `monitoring.yaml`. Used to monitor packages for releases and security advisories; see [monitoring.yaml](docs/packaging/monitoring.yaml.md).
 - This is not enforced by automatic checks yet, but we may ask that it be added.
 
 ## 2023

docs/packaging/prepare-for-packaging.md

@@ -40,7 +40,7 @@ We need to install a few things in order to get started with packaging:
 - `solbuild` is a lightweight container environment for building packages repeatably
 - `solbuild-config-unstable` sets up solbuild for working with the `unstable` repository
 - `ypkg` is the program that actually builds packages
-- `yq` is used by the `go-task add-monitoring` command to create new [`monitoring.yml`](/docs/packaging/monitoring.yml.md) files
+- `yq` is used by the `go-task add-monitoring` command to create new [`monitoring.yaml`](/docs/packaging/monitoring.yaml.md) files
 
 ```bash
 sudo eopkg it ent git github-cli go-task jq solbuild solbuild-config-unstable ypkg yq
@@ -185,7 +185,7 @@ You should now have the following available from your shell:
 
 | Function          | Description                                                                                                                                  | Usage                         |
 | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
-| **cpesearch**     | Search for CPE Names for packages. For use when writing the[`monitoring.yml`](/docs/packaging/monitoring.yml.md) file for a package          | `cpesearch search-term`       |
+| **cpesearch**     | Search for CPE Names for packages. For use when writing the[`monitoring.yaml`](/docs/packaging/monitoring.yaml.md) file for a package          | `cpesearch search-term`       |
 | **goroot**        | When in the Solus packages repository, change directory to the root directory.                                                               | `goroot`                      |
 | **gotopkg**       | Change directory to any Solus package. You can type part of the package name then double press`Tab` to get autocompletion for this function. | `gotopkg firefox`             |
 | **gotosoluspkgs** | Change directory to the Solus packages repository from anywhere on the filesystem.                                                           | `gotosoluspkgs`               |

docs/packaging/submitting-a-pull-request.mdx

@@ -27,7 +27,7 @@ At minimum, your pull request will include changes for the following files:
 It may also include these files:
 
 - `MAINTAINERS.md`
-- `monitoring.yml`
+- `monitoring.yaml`
 
 Double check the `package.yml` to make sure the builddeps are in the right order, and that it otherwise adheres to the [standards](package.yml.md) Solus has set.
 

docs/packaging/updating-an-existing-package.md

@@ -176,8 +176,8 @@ In the cases where you are not updating a package to a new version, but simply a
   - `package: Add homepage`
 - Fix a packaging issue (including adding a patch to fix the package)
   - `package: Fix (...)`
-- Updating a README, [monitoring.yml file](monitoring.yml.md) or other stuff that does not directly _change_ the package, meaning the package release number didn't need a bump:
-  - `package: [NFC] Add README.md and monitoring.yml`
+- Updating a README, [monitoring.yaml file](monitoring.yaml.md) or other stuff that does not directly _change_ the package, meaning the package release number didn't need a bump:
+  - `package: [NFC] Add README.md and monitoring.yaml`
 
 As stated previously, `[NFC]` is an abbreviation of "No Functional Change".