Replace Maven Cache with Mimír

[ppkarwasz]

This pull request replaces the use of the Maven local repository cache with Mimír, a specialized, immutable cache for remote Maven repositories.

Description

The Maven local repository serves multiple purposes:

• Mirrors immutable releases from Maven Central
• Caches snapshot artifacts
• Acts as a local staging area for builds

Because of these overlapping responsibilities, the local repository often becomes polluted with temporary artifacts, making it unreliable for consistent, reproducible builds. Additionally, it is not safe to share across workflows.

One major issue caused by sharing the local Maven repository is the occurrence of false negatives in the verify-reproducibility-reusable check (see #388).

Benefits of Using Mimír

Mimír provides a cleaner and more reliable caching approach:

• Immutable by design: Only caches artifacts from remote Maven repositories, which do not change.
• Workflow-friendly: Enables a single shared cache across workflows without risk of contamination from snapshots or local artifacts.

This change improves build reproducibility, reduces cache-related issues, and simplifies cache management.

Fixes #388

[ppkarwasz]

I am marking this as draft, since there are still some details of actions/cache I need to work on. The ultimate goal is to have a single cache that is updated when new dependency version arrive.

[Copilot]

Pull Request Overview

This PR replaces the Maven local repository cache with Mimír to ensure immutable, reproducible builds while reducing cache-related issues. Key changes include updating the pom.xml to add Mimír configuration, adding a changelog entry for Mimír, and integrating Mimír setup steps into multiple GitHub workflow files.

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/changelog/.12.x.x/add-mimir.xml	Adds changelog entry documenting the adoption of Mimír
pom.xml	Introduces Mimír version property and two plugin entries for Mimír
.github/workflows/verify-reproducibility-reusable.yaml	Adds Mimír caching configuration for improved reproducibility
.github/workflows/merge-dependabot-reusable.yaml	Adds Mimír caching configuration along with necessary comments
.github/workflows/deploy-snapshot-reusable.yaml	Introduces Mimír setup steps for snapshot deployment workflows
.github/workflows/deploy-site-reusable.yaml	Integrates Mimír configuration into the site deployment workflow
.github/workflows/deploy-release-reusable.yaml	Integrates Mimír caching configuration into the release deployment
.github/workflows/codeql-analysis-reusable.yaml	Adds Mimír caching steps into the code analysis workflow
.github/workflows/build-reusable.yaml	Configures Mimír caching using actions/cache for the build workflow

[ppkarwasz]

I forgot to mention that I deployed the same solution in sbom-enforcer/sbom-enforcer a couple of weeks ago and it seems to work correctly so far.

[vy]

This PR

1. adds net 260 lines,
2. uses a plugin whose README states that

   this code is Proof of Concept, with a lot of To-Be-Done parts

3. for a problem (Inconsistent Reproducibility Verification Due to Shared Maven Cache #388), which can also be solved in other simpler ways:
   1. Avoid using the Maven local repository cache in the verify-reproducibility-reusable workflow.
   2. Use a dedicated Maven cache specifically for the verify-reproducibility-reusable workflow, separate from the one used by build and deploy workflows.

Mimir is not a widely used plugin, no Logging Services PMC member possess experience with it, the problem at hand is not severe, and there are simpler and more familiar ways to fix the issue. @ppkarwasz, from a maintenance pov, can't we fix the issue by simply adjusting the verify-reproducibility-reusable workflow as you suggested?

[ppkarwasz]

In the long run I would prefer to use a solution like Mimír to ensure that we only have a single reliable cache without locally built artifacts that can be reused in all workflows.

In the meantime I created #406 that uses a separate cache for the verify-reproducibility workflow.

[vy]

single reliable cache without locally built artifacts that can be reused in all workflows.

Doesn't #406 deliver this?

In the meantime I created #406 that uses a separate cache for the verify-reproducibility workflow.

Thanks so much for your understanding and kind effort – approved.