Update common files (#392)

.github/renovate.json

@@ -0,0 +1,12 @@
+{
+  "extends": [
+    "config:base"
+  ],
+  "addLabels": ["dependency-upgrade"],
+  "schedule": [
+    "every weekend"
+  ],
+  "prHourlyLimit": 1,
+  "prConcurrentLimit": 20,
+  "timezone": "Europe/Prague"
+}

.github/workflows/graalvm.yml

@@ -54,6 +54,7 @@ jobs:
            GRADLE_ENTERPRISE_ACCESS_KEY: ${{ secrets.GRADLE_ENTERPRISE_ACCESS_KEY }}
            GRADLE_ENTERPRISE_CACHE_USERNAME: ${{ secrets.GRADLE_ENTERPRISE_CACHE_USERNAME }}
            GRADLE_ENTERPRISE_CACHE_PASSWORD: ${{ secrets.GRADLE_ENTERPRISE_CACHE_PASSWORD }}
+           PREDICTIVE_TEST_SELECTION: "${{ github.event_name == 'pull_request' && 'true' || 'false' }}"
       - name: Publish Test Report
         if: always()
         uses: mikepenz/action-junit-report@v3.0.2

.github/workflows/gradle.yml

@@ -57,6 +57,7 @@ jobs:
            GRADLE_ENTERPRISE_ACCESS_KEY: ${{ secrets.GRADLE_ENTERPRISE_ACCESS_KEY }}
            GRADLE_ENTERPRISE_CACHE_USERNAME: ${{ secrets.GRADLE_ENTERPRISE_CACHE_USERNAME }}
            GRADLE_ENTERPRISE_CACHE_PASSWORD: ${{ secrets.GRADLE_ENTERPRISE_CACHE_PASSWORD }}
+           PREDICTIVE_TEST_SELECTION: "${{ github.event_name == 'pull_request' && 'true' || 'false' }}"
       - name: Publish Test Report
         if: always()
         uses: mikepenz/action-junit-report@v3.0.2

MAINTAINING.md

@@ -88,7 +88,7 @@ follow a slightly different strategy.
 
 All Micronaut repos have 2 dependency upgrade checking mechanism:
 
-1. Dependabot: it has the advantage that it performs dependency upgrades not only on build dependencies, but also on
+1. Renovate: it has the advantage that it performs dependency upgrades not only on build dependencies, but also on
    GitHub Actions workflows. On the other hand, its biggest downside is that it's unable to find newer versions for
    those defined in `gradle.properties`. It will also send different PRs for the same version upgrade if the artifact ID
    is different. For example, if you have `com.example:client:1.0` and `com.example:server:1.0`, and a new 1.1 version
@@ -99,9 +99,9 @@ All Micronaut repos have 2 dependency upgrade checking mechanism:
    during weekdays.
 
 The consequence of having both approaches in place is that we get multiple dependency upgrade PRs: one created by
-`micronaut-build` via our automation, and one or many (one per dependency) created by Dependabot. When merging those, it
+`micronaut-build` via our automation, and one or many (one per dependency) created by Renovate. When merging those, it
 is better to prefer the `micronaut-build` ones, if possible, for 2 reasons: a) they attempt to upgrade multiple dependencies
-in a single PR, which creates less noise in the Git history; b) Once you merge that, Dependabot will react and automatically
+in a single PR, which creates less noise in the Git history; b) Once you merge that, Renovate will react and automatically
 close its own PRs if the dependecy is up-to-date.
 
 When an upgrade to a new version arrives, we need to be careful when merging, so that we don't introduce an
@@ -111,7 +111,7 @@ information.
 
 Note that if a new version arrives and we are not ready yet to do the upgrade, you need to
 [pin the old version](https://github.com/micronaut-projects/micronaut-build/#configuration-options), because otherwise,
-Dependabot and our workflow will keep sending PRs. You should also create an issue to upgrade so that it's not forgotten.
+Renovate and our workflow will keep sending PRs. You should also create an issue to upgrade so that it's not forgotten.
 
 #### Files sync
 
@@ -126,7 +126,7 @@ template repo will get propagated automatically. The files propagated are:
   * `gradle.yml`.
   * `release.yml`.
   * `release-notes.yml`.
-* Dependabot configuration (`.github/dependabot.yml`).
+* Renovate configuration (`.github/renovate.json`).
 * Gradle wrapper.
 * `.gitignore`.
 * `ISSUE_TEMPLATE.md`, `LICENSE`, `MAINTAINING.md`, `config/HEADER` and `config/spotless.license.java`.