ci: unify auto-merge across bots

.github/workflows/dependabot-auto-merge.yml → .github/workflows/auto-merge.yml

@@ -1,4 +1,4 @@
-name: 'Linuxfabrik: Dependabot auto-merge'
+name: 'Linuxfabrik: Auto-merge'
 
 on:
   pull_request: {}
@@ -17,7 +17,7 @@ env:
   FROZEN_LOCKFILES: '["pip:/"]'
 
 jobs:
-  auto-merge:
+  dependabot:
     runs-on: 'ubuntu-latest'
     if: 'github.actor == ''dependabot[bot]'''
     permissions:
@@ -63,3 +63,24 @@ jobs:
         env:
           GH_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
           PR_URL: '${{ github.event.pull_request.html_url }}'
+
+  # The weekly hook bump carries nothing but `rev:` changes in
+  # .pre-commit-config.yaml, and it arrives in every repository at once.
+  # Merging that by hand is pure overhead, so it goes in as soon as the
+  # required checks pass. The same fallback as above applies, and it is only
+  # safe because the ruleset keeps enforcing those checks server-side.
+  pre-commit-autoupdate:
+    runs-on: 'ubuntu-latest'
+    if: >-
+      github.actor == 'linuxfabrik-automation[bot]'
+      && github.head_ref == 'chore/pre-commit-autoupdate'
+    permissions:
+      contents: 'write'
+      pull-requests: 'write'
+    steps:
+
+      - run: |
+          gh pr merge --auto --squash "$PR_URL" || gh pr merge --squash "$PR_URL"
+        env:
+          GH_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
+          PR_URL: '${{ github.event.pull_request.html_url }}'

README.md

@@ -76,13 +76,13 @@ Full documentation is available at [linuxfabrik.github.io/checklistfabrik](https
 
 ## Definitions and Terms
 
-* **Checklist:**  
+* **Checklist:**
   A series of tasks outlining a procedure, organized into pages.
 
-* **Page:**  
+* **Page:**
   A collection of tasks displayed simultaneously to the user.
 
-* **Report:**  
+* **Report:**
   The output of a checklist run—a YAML file generated from a template.
 
 * **Task:**

examples/templates/feature-showcase.yml

@@ -11,23 +11,23 @@ pages:
           content: |
             ChecklistFabrik can store user input for later use.
             The `fact_name` task key controls under which name the data will be available.
-            
+
             ```yaml
             - linuxfabrik.clf.text_input:
                 label: 'Hostname'
                 required: true
               fact_name: 'hostname'
             ```
-            
+
             The user's input can then be used on subsequent pages like this:
-            
+
             {% raw %}
-            
+
             ```yaml
             - linuxfabrik.clf.checkbox_input:
                 label: 'Allow access to SSH on {{ hostname }}'
             ```
-            
+
             {% endraw %}
 
       - linuxfabrik.clf.text_input:
@@ -48,9 +48,9 @@ pages:
           content: |
             In ChecklistFabrik pages and tasks can be conditionally shown based on previous user input.
             This can be achieved by using Jinja conditional expressions in a page's or task's `when` key.
-            
+
             There is no need to surround variables in conditionals with double curly braces.
-            
+
             ```yaml
             - title: 'Example 2 - OS Selection'
               tasks:
@@ -61,26 +61,26 @@ pages:
                       - 'MacOS'
                       - 'Windows'
                     fact_name: 'install_type'
-            
+
                 - linuxfabrik.clf.select_input:
                     label: 'Variant'
                     values:
                       - 'Hardware Machine'
                       - 'Virtual Machine'
                   fact_name: 'install_variant'
-            
+
             - title: 'Example 2 - Install Linux'
               tasks:
                 - linuxfabrik.clf.markdown:
                     content: 'This page can only be seen if "Linux" has been selected.'
-            
+
                 - linuxfabrik.clf.markdown:
                     content: 'This task is only visible if "Virtual Machine" was selected'
                   when: 'install_variant | lower() == "virtual machine"'
-            
+
               when: 'install_type | lower() == "linux"'
             ```
-            
+
             See the next pages on how this example works in practice.
 
   - title: 'Example 2 - OS Selection'
@@ -117,7 +117,7 @@ pages:
           content: |
             Multiple `when` conditionals are combined with a logical `and`;
             the following example requires that both conditionals evaluate to true:
-            
+
             ```yaml
             - title: 'Example 3 - Programming Languages'
               tasks:
@@ -128,7 +128,7 @@ pages:
                       - value: 'Kotlin'
                       - value: 'Python'
                   fact_name: 'language'
-            
+
             - title: 'Example 3 - Python C Interop'
               tasks:
                 - linuxfabrik.clf.markdown:
@@ -138,9 +138,9 @@ pages:
                 - '"c" in (language | map("lower"))'
                 - '"python" in (language | map("lower"))'
             ```
-            
+
             Jinja's logical operators can also be used to combine conditions and construct more complex conditions:
-            
+
             ```yaml
             - title: 'Example 3 - JDK'
               tasks:
@@ -149,7 +149,7 @@ pages:
                       Install a suitable JDK.
               when: '"java" in (language | map("lower") or "kotlin" in (language | map("lower")'
             ```
-            
+
             See the next pages on how this example works in practice.
 
   - title: 'Example 3 - Programming Languages'
@@ -183,43 +183,43 @@ pages:
       - linuxfabrik.clf.markdown:
           content: |
             ChecklistFabrik templates can suggest where the report should be saved.
-            
+
             Using the following example, ChecklistFabrik will save the generated report to `report_path_checklist.yml`.
-            
+
             ```yaml
             title: 'report_path Example Checklist'
             report_path: 'report_path_checklist.yml'
             ```
-            
+
             The `report_path` *will only be used* if no file argument is specified,
             i.e. the file parameter was omitted from the commandline: `clf-play --template report_path_template.yml`
-            
+
             This allows users to simply override the template provided save location by specifying the file parameter on the commandline:
             `clf-play --template report_path_template.yml overridden_save_location.yml`
 
       - linuxfabrik.clf.markdown:
           content: |
             Environment variables (of the form `$name` or `${name}`) in `report_path` are expanded.
             Therefore, the next example would result in the report being saved under `~/report_path_checklist.yml`.
-            
+
             ```yaml
             title: 'report_path Example Checklist'
             report_path: '$HOME/report_path_checklist.yml'
             ```
-            
+
             Malformed variable names and references to non-existing variables are left unchanged.
             Windows user may also specify variables using `%name%` (this will, however, *not* be expanded on other platforms).
-            
+
       - linuxfabrik.clf.markdown:
           content: |
             For more control over the `report_path` Jinja templating can also be used.
-            
+
             This showcase, for example, uses the following Jinja templated `report_path`:
-            
+
             {% raw %}
-            
+
             ```yaml
             report_path: 'feature-showcase-{{ now().strftime("%Y%m%d") }}.yml'
             ```
-            
+
             {% endraw %}

examples/templates/import-showcase.yml

@@ -9,23 +9,23 @@ pages:
       - linuxfabrik.clf.markdown:
           content: |
             ChecklistFabrik supports importing tasks from separate YAML files.
-            
+
             To import tasks the special `linuxfabrik.clf.import` module can be used:
-            
+
             ```yaml
             pages:
               - title: 'Page with Imported Tasks'
                 tasks:
                   - linuxfabrik.clf.import: 'import-additional-tasks.yml'
             ```
-            
+
             There are a few important details about task imports:
-            
+
             - Relative import paths are always relative to the importing file.
             - Imported tasks will be flattened into the saved file.
             - The file to import *must* be formatted as a list of tasks (even if it only contains one task).
             - Importing a file in an already imported file is supported.
-            
+
             The following tasks were imported from `import-additional-tasks.yml`:
 
       - linuxfabrik.clf.import: 'import-additional-tasks.yml'
@@ -36,21 +36,21 @@ pages:
       - linuxfabrik.clf.markdown:
           content: |
             Additionally, ChecklistFabrik also supports importing full pages.
-            
+
             This works similarly to importing tasks, but on the page level:
-            
+
             ```yaml
             pages:
               - linuxfabrik.clf.import: 'import-additional-pages.yml'
             ```
-            
+
             There are a few important details about task imports:
-            
+
             - Relative import paths are always relative to the importing file.
             - Imported pages will be flattened into the saved file.
             - The file to import *must* be formatted as a list of pages (even if it only contains one page).
             - Importing a file in an already imported file is supported.
-            
+
             The next page was imported from `import-additional-pages.yml`:
 
   - linuxfabrik.clf.import: 'import-additional-pages.yml'