Add a reusable spring-trigger-dependabot-updates.yml workflow

* Replace `[artifactory-release]` prefix in a commit message to the `[CI/CD]` for better generic context
* Fix `artifactoryPublish` Gradle task to the `publishAllPublicationsToDeploymentRepository`
in the `spring-artifactory-gradle-release.yml` `buildToolArgs` input description
* Fix typos in the `README.md`
* Mention `spring-trigger-dependabot-updates.yml` in the `README.md`

Author: artembilan

.github/workflows/spring-artifactory-gradle-release.yml

@@ -4,7 +4,7 @@ on:
   workflow_call:
     inputs:
       buildToolArgs:
-        description: 'Additional Gradle command arguments: tasks, options etc. The `build` and `artifactoryPublish` for Gradle are included.'
+        description: 'Additional Gradle command arguments: tasks, options etc. The `build` and `publishAllPublicationsToDeploymentRepository` for Gradle are included.'
         required: false
         type: string
       artifactoryUrl:

.github/workflows/spring-finalize-release.yml

@@ -48,7 +48,7 @@ jobs:
           git fetch origin --no-tags
           git pull origin ${{ github.ref }}
           
-          git commit -a -m "[artifactory-release] Release version ${{ inputs.milestone }}"
+          git commit -a -m "[CI/CD] Release version ${{ inputs.milestone }}"
           git tag "v${{ inputs.milestone }}"
           
           NEXT_VERSION="${{ inputs.milestone }}"
@@ -72,7 +72,7 @@ jobs:
             sed -i "s/version=.*/version=$NEXT_VERSION/" gradle.properties
           fi
           
-          git commit -a -m "[artifactory-release] Next development version"
+          git commit -a -m "[CI/CD] Next development version"
           git push origin
           git push --tags origin
           

.github/workflows/spring-trigger-dependabot-updates.yml

@@ -0,0 +1,32 @@
+name: Trigger Dependabot Updates
+
+# This workflow is a convenient alternative to the GitHub UI interface for Dependabot updates.
+# The workflow performs Toggle executable permission as a superficial change on the dependabot.yml file.
+# That is enough for Dependabot to understand that some changes have happened in the dependency updates config.
+
+on:
+  workflow_call:
+    secrets:
+      GH_ACTIONS_REPO_TOKEN:
+        required: true
+
+jobs:
+  trigget-dependabot:
+    runs-on: ubuntu-latest
+    steps:
+
+      - uses: actions/checkout@v6
+        with:
+          token: ${{ secrets.GH_ACTIONS_REPO_TOKEN }}
+          show-progress: false
+
+      - name: Touch dependabot.yml
+        run: |
+          file=".github/dependabot.yml"
+          # Toggle executable permission as a superficial change
+          [ -x "$file" ] && chmod -x "$file" || chmod +x "$file"
+          
+          git config --global user.name 'Spring Builds'
+          git config --global user.email 'builds@springframework.org'
+          git commit -am "CI/CD: Trigger dependabot updates"
+          git push origin

README.md

@@ -27,9 +27,9 @@ The `SPRING_RELEASE_CHAT_WEBHOOK_URL` secret is also optional: probably you don'
 As well as `OSSRH_*` secret, since not all releases might go to Maven Central, e.g. private (commercial) repositories only.
 Also, the `OSSRH_*` and `CENTRAL_TOKEN_*` secrets are mutually exclusive where `CENTRAL_TOKEN_*` will lead to publishing via [Maven Central Portal](https://central.sonatype.org/register/central-portal/). 
 
-The mentioned secrets must be passed explicitly since these reusable workflows might be in different GitHub org than target project.
+The mentioned secrets must be passed explicitly since these reusable workflows might be in a different GitHub org than the target project.
 
-The SNAPSHOT and Release workflows uses [spring-io/artifactory-deploy-action](https://github.com/spring-io/artifactory-deploy-action) to publish artifacts into Artifactory.
+The SNAPSHOT and Release workflows use [spring-io/artifactory-deploy-action](https://github.com/spring-io/artifactory-deploy-action) to publish artifacts into Artifactory.
 
 ## Build SNAPSHOT and Pull Request Workflows
 
@@ -43,7 +43,7 @@ https://github.com/spring-io/spring-github-workflows/blob/29fd75ff06da2789a1fcd9
 #### Maven Pull Request caller workflow:
 https://github.com/spring-io/spring-github-workflows/blob/29fd75ff06da2789a1fcd9b1732bf8bce4704fa6/samples/pr-build-maven.yml#L1-L10
 
-You can add more branches to react for pull request events.
+You can add more branches to react to pull request events.
 
 The SNAPSHOT workflows ([spring-artifactory-gradle-snapshot.yml](.github/workflows/spring-artifactory-gradle-snapshot.yml) and [spring-artifactory-maven-snapshot.yml](.github/workflows/spring-artifactory-maven-snapshot.yml), respectively) are also that simple.
 They publish artifacts into `libs-snapshot-local` (by default) repository.
@@ -64,10 +64,10 @@ The [spring-artifactory-gradle-release.yml](.github/workflows/spring-artifactory
 
 - The versioning schema must follow these rules: 3-digit-dotted number for `major`, `minor` and `patch` parts, snapshot is suffixed with `-SNAPSHOT`, milestones are with `-M{number}` and `-RC{number}` suffix, the GA release is without any suffix.
 For example: `0.0.1-SNAPSHOT`, `1.0.0-M1`, `2.1.0-RC2`, `3.3.3`.
-- GitHub Milestone titles must be exact as the version to release number.
+- GitHub Milestone titles must be exact as the version-to-release number.
 For example: `1.0.0-M1`, `2.1.0-RC2`, `3.3.3`.
 - GitHub Milestones must be scheduled: have a `Due on` date set.
-Otherwise, release workflow will be cancelled with a warning that nothing to release for respective SNAPSHOT in a branch.
+Otherwise, the release workflow will be cancelled with a warning that nothing to release for the respective SNAPSHOT in a branch.
 
 The logic of this release workflow:
 
@@ -80,25 +80,25 @@ This job stages released artifacts using JFrog Artifactory plugin into `libs-sta
 - The next job is to [verify staged artifacts](#verify-staged-artifacts)
 - When verification is successful, next job promotes release from staging either to `libs-milestone-local` or `libs-release-local` (by default) (and optional to Maven Central: if `bundleName` input is not provided) according to the releasing version schema
 - Then [spring-finalize-release.yml](.github/workflows/spring-finalize-release.yml) job is executed, which tags release into GitHub, commits next development version, generates release notes using [Spring Changelog Generator](https://github.com/spring-io/github-changelog-generator) excluding repository admins from `Contributors` section.
-The `gh release create` command is performed on a tag for just released version.
-Then spring.io project page is updated for newly released version.
+The `gh release create` command is performed on a tag for a just released version.
+Then `spring.io` project page is updated for a newly released version.
 (The [spring-website-project-version-update](.github/actions/spring-website-project-version-update) local action is implemented for this goal).
-And in the end the milestone closed and specific Google Space notified about release (if `SPRING_RELEASE_CHAT_WEBHOOK_URL` secret is present in the repository).
+And in the end the milestone closed, and specific Google Space notified about release (if `SPRING_RELEASE_CHAT_WEBHOOK_URL` secret is present in the repository).
 
 #### Example of Release caller workflow:
 https://github.com/spring-io/spring-github-workflows/blob/88d5c5f78e88d00b9ad18885438d4e3657433ccf/samples/release-with-gradle.yml#L1-L24
 
-Such a workflow must be on every branch which is supposed to be released via GitHub actions.
+Such a workflow must be on every branch that is supposed to be released via GitHub actions.
 
 The `buildToolArgs` parameter for this job means extra build tool arguments.
 For example, the mentioned `dist` value is a Gradle task in the project.
 Can be any Maven goal or other command line arguments.
 
 The signing released artifacts is done by the [spring-io/artifactory-deploy-action](https://github.com/spring-io/artifactory-deploy-action) if `GPG_PASSPHRASE` and `GPG_PRIVATE_KEY` secrets are provided.
-In the end all the artifacts, together with their signatures, are uploaded to the Artifactory according to the respective workflow inputs.  
+In the end, all the artifacts, together with their signatures, are uploaded to the Artifactory according to the respective workflow inputs.  
 
-In the end you just need to go to the `Actions` tab on your project, press `Run workflow` on your release workflow and choose a branch from drop-down list to release currently scheduled Milestone against. 
-Such a release workflow can also be scheduled (`cron`, fo example) against branches matrix.
+In the end you just need to go to the `Actions` tab on your project, press `Run workflow` on your release workflow and choose a branch from a drop-down list to release currently scheduled Milestone against. 
+Such a release workflow can also be scheduled (`cron`, for example) against branches matrix.
 
 #### Scheduler workflow example:
 https://github.com/spring-io/spring-github-workflows/blob/78b29123a17655f019d800690cc906d692f836a9/samples/schedule-releases.yml#L1-L19
@@ -112,9 +112,9 @@ https://github.com/spring-io/spring-github-workflows/blob/78b29123a17655f019d800
 
 The `verify-staged` job expects an optional `verifyStagedWorkflow` input (the `verify-staged-artifacts.yml`, by default) workflow supplied from the target project.
 For example, [Spring Integration for AWS](https://github.com/spring-projects/spring-integration-aws) uses `jfrog rt download` command to verify that released `spring-integration-aws-${{ inputs.releaseVersion }}.jar` is valid.
-Other projects may check out their samples repository and setup release version to perform smoke tests against just staged artifacts.
+Other projects may check out their samples repository and set up release version to perform smoke tests against just staged artifacts.
 
-#### Verify staged workflow sample:
+#### Verify the staged workflow sample:
 https://github.com/spring-io/spring-github-workflows/blob/78b29123a17655f019d800690cc906d692f836a9/samples/verify-staged-artifacts.yml#L1-L28
 
 ## Backport GitHub Issue Workflow
@@ -127,19 +127,19 @@ https://github.com/spring-io/spring-github-workflows/blob/521ac488abc90d96170403
 
 ## Dependabot Support
 
-If [Dependabot](https://github.com/dependabot) is enabled for repository, its config should set a label compatible with [Spring Changelog Generator](https://github.com/spring-io/github-changelog-generator).
+If [Dependabot](https://github.com/dependabot) is enabled for the repository, its config should set a label compatible with [Spring Changelog Generator](https://github.com/spring-io/github-changelog-generator).
 Typically, it is `type: dependency-upgrade`.
 It is also a good practice to group all the development dependencies into a single pull request from Dependabot.
 This includes all the Gradle and Maven plugins and those dependencies which are used only for testing in the project.
-This projects provides a [spring-merge-dependabot-pr.yml](.github/workflows/spring-merge-dependabot-pr.yml) reusable workflow to make modifications to the Dependabot pull requests.
+This project provides a [spring-merge-dependabot-pr.yml](.github/workflows/spring-merge-dependabot-pr.yml) reusable workflow to make modifications to the Dependabot pull requests.
 However, there are some prerequisites to use this workflow in your project:
-- Pull requests must be protected by some check to pass, usually a workflow to build the project with this pull request changes;
+- Pull requests must be protected by some check to pass, usually a workflow to build the project with these pull request changes;
 - The [auto-merge](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-auto-merge-for-pull-requests-in-your-repository) must be enabled in the repository (if `--auto` is used);
 
 The `spring-merge-dependabot-pr` workflow does these modifications to the Dependabot pull requests:
 - Modify label from `dependency-upgrade` to the `task` for the development dependencies group update to skip them from release notes by Spring Changelog Generator;
 - Adds a currently scheduled milestone to the pull request against a snapshot version extracted from the target branch;
-- And if milestone is scheduled, the pull request is queued for auto-merging after required checks have passed;
+- And if a milestone is scheduled, the pull request is queued for auto-merging after required checks have passed;
 - If `autoMergeSnapshots` input is set to `true`, the upgrade from Milestone/Release Candidate dependency to its SNAPSHOT is going to be merged automatically without assigning a milestone to the PR.   
 
 The `mergeArguments` input of this workflow is applied to the `gh pr merge` command. 
@@ -149,7 +149,7 @@ https://github.com/spring-io/spring-github-workflows/blob/521ac488abc90d96170403
 
 ## Automatic cherry-pick workflow
 
-The [spring-cherry-pick.yml](.github/workflows/spring-cherry-pick.yml) workflow offers a logic to cherry-pick pushed commit to branches suggested by the specific sentence in commit message.
+The [spring-cherry-pick.yml](.github/workflows/spring-cherry-pick.yml) workflow offers a logic to cherry-pick pushed commit to branches suggested by the specific sentence in the commit message.
 For example `Auto-cherry-pick to 6.2.x & 6.1.x`.
 The `Auto-cherry-pick` token is a default value for the `autoCherryPickToken` input of this workflow.
 The branches to cherry-pick to are extracted from the matching sentence.
@@ -175,6 +175,12 @@ jobs:
 ```
 The workflow reacts to non-empty `due_on` property of the event's milestone payload and check if this property really was changed on milestone edit. 
 
+## Trigger Dependabot Updates
+
+The [spring-trigger-dependabot-updates.yml](.github/workflows/spring-trigger-dependabot-updates.yml) workflow is a convenient alternative to the GitHub UI interface for Dependabot updates ($GH_REPOSITORY/network/updates).
+The workflow performs toggle executable permission as a superficial change on the `dependabot.yml` file.
+That is enough for Dependabot to understand that some changes have happened in the dependency updates config to trigger new versions check.
+
 ## "Dispatch Workflow and Wait" Action
 
 The [spring-dispatch-workflow-and-wait](.github/actions/spring-dispatch-workflow-and-wait/action.yml) action implements the logic to call `gh workflow run` for the provided workflow file and wait until it is complete, successful or not.