New .github repo in the XWiki GH organization for shared GitHub configuration

Development
1

Hi devs,

Following the +1s in Running sonarqube checks for PRs, I’ve created GitHub - xwiki/.github: GitHub configuration shared by the XWiki repositories: default community health files, reusable workflows and the Renovate preset · GitHub to hold the GitHub configuration that commons, rendering and platform were each maintaining their own copy of.

What’s in it

.github/pull_request_template.md   org-wide default
.github/SECURITY.md                org-wide default
.github/FUNDING.yml                org-wide default
.github/workflows/quality-pr.yml   reusable workflow
.github/workflows/backport.yml     reusable workflow
renovate/default.json5             shared Renovate preset

A repo named .github gives us two separate mechanisms, and we use both:

  • Default community health files are inherited automatically by every public repo of the org that doesn’t define its own. Nothing to add in a repo — deleting its own copy is what makes the default apply. SECURITY.md is a nice side effect here: every XWiki repo that has no security policy today gets one, pointing at https://dev.xwiki.org/xwiki/bin/view/Community/SecurityPolicy/.
  • Workflows are NOT inherited. Each repo keeps a small stub calling the shared implementation.

What this changes for you

Edit shared workflows in xwiki/.github, not in the three repos. quality-pr.yml was 505 lines duplicated three times; it’s now one file. The stubs reference @master, so a change there reaches all three repos on their next run — which also means a PR on xwiki/.github has to be reviewed as a change to all three at once.

The PR check is now named Quality / Analyze instead of Analyze. A reusable workflow always composes <caller job> / <called job>, there’s no way around the two levels. No branch protection rule required a check by name, so nothing broke.

The stub is close to what I sketched in the proposal, with two differences:

jobs:
  analysis:
    name: Quality
    if: github.event.pull_request.head.repo.full_name == github.repository
    permissions:
      contents: read
    uses: xwiki/.github/.github/workflows/quality-pr.yml@master
    secrets:
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

@tmortagne was right that java-version shouldn’t be there — there’s no such input, the JDK is read from xwiki.java.version in the effective root pom, as before. And SONAR_TOKEN is passed explicitly rather than secrets: inherit, so the shared workflow only ever gets the one secret it needs. The fork guard has to stay in the stub: a skipped job never resolves its secrets, which is what keeps fork PRs from failing on a missing required SONAR_TOKEN.

For Renovate, only what all three shared moved out — the rest genuinely differs per repo:

{
  "extends": ["github>xwiki/.github//renovate/default.json5"],
  // ... whatever is specific to this repo
}

One trap worth knowing: Renovate concatenates packageRules from the preset (preset first) but replaces every other array. So a repo needing an extra ignoreDeps entry has to repeat the preset’s entries alongside its own — commons does.

One deliberate deviation

The stubs reference @master rather than a commit hash, which trips SonarQube’s githubactions:S7637 (“use full commit SHA hash for this dependency”) — the new PR gate duly failed its own PRs on that, which was a decent smoke test. I’ve marked those issues Accepted rather than pinning: the rule guards against a third party repointing a mutable ref, which isn’t really the situation for a repo the XWiki committers own, and pinning would mean a PR in all three repos for every change to a shared workflow — most of the duplication this removes. Happy to revisit if anyone feels strongly. The reasoning is in a comment next to each uses: line so it isn’t only recorded in SonarCloud.

PRs

All green, review welcome (already merged):

Each removes ~550 lines. Note xwiki-contrib is a separate GH organization, so extending this there means its own .github repo — the reusable workflows here can be called from it either way, since the repo is public.

Hope you like it.

Thanks

2

Note that sharing SECURITY.md and even pull_request_template.md is not exactly right for all repos. OTOH I don’t think it’s too much of an issue and I see more pros than cons. Let me know if you don’t share that vision.