fix: Maven Toolchains grows unexpectedly#534
Conversation
82fce8d to
c30cb6d
Compare
c30cb6d to
b8162e8
Compare
|
Hey guys, this is a potential fix for my case. I would appreciate if we can test this out or merged it. |
b8162e8 to
e53962a
Compare
e53962a to
d823120
Compare
d823120 to
301593b
Compare
On self-hosted runners toolchains.xml may survive multiple runs and unexpectedly grow as a result of the toolchains setup simply appending the JDK definition even if one with the same `type` and `provides.id` already exists. Restructuring the parsing step and filtering the potentially existing list of toolchain definitions prevents this and also fixes toolchain.xml files that already contain duplicates. Fixes actions#530
301593b to
36b7a1c
Compare
|
@brunoborges I'll have a look in a day or two I hope. Didn't have the time since the last release to fix this yet. Thanks for helping out with the rebase. Feel free to look at #553 first and I'll update my PR after if you can already merge that. |
|
Linking the tracking issue: this PR implements #530 (Maven toolchains.xml unexpected growth). Maintainers — adding |
There was a problem hiding this comment.
Pull request overview
This PR addresses Maven toolchains.xml “overgrowth” on self-hosted runners by parsing existing toolchain entries and filtering out duplicate JDK toolchains (same type + provides.id) before writing the updated file.
Changes:
- Parse existing
toolchains.xmlinto JS objects and merge with the new JDK toolchain entry. - Deduplicate JDK toolchain definitions (while leaving non-JDK toolchains untouched).
- Expand unit tests to cover deduplication and preservation of custom toolchain elements; update the compiled
dist/output accordingly.
Show a summary per file
| File | Description |
|---|---|
src/toolchains.ts |
Refactors toolchains generation to parse existing XML, merge toolchains, and deduplicate JDK entries. |
dist/setup/index.js |
Updates the compiled action bundle to reflect the new toolchains logic. |
__tests__/toolchains.test.ts |
Adds/updates tests for deduplication behavior and preservation of custom toolchain content. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 2/3 changed files
- Comments generated: 2
| jsToolchains = jsToolchains.filter( | ||
| (value, index, self) => | ||
| // ensure non-jdk toolchains are kept in the results, we must not touch them because they belong to the user | ||
| value.type !== 'jdk' || | ||
| index === | ||
| self.findIndex( | ||
| t => t.type === value.type && t.provides.id === value.provides.id | ||
| ) | ||
| ); |
| // TODO: technically bad because we shouldn't re-create the toolchains root node (with possibly different schema values) if it already exists, however, just overriding the toolchain array with xmlbuilder2 is … uh non-trivial | ||
| return xmlCreate({ | ||
| toolchains: { | ||
| '@xmlns': 'http://maven.apache.org/TOOLCHAINS/1.1.0', | ||
| '@xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance', | ||
| '@xsi:schemaLocation': | ||
| 'http://maven.apache.org/TOOLCHAINS/1.1.0 https://maven.apache.org/xsd/toolchains-1.1.0.xsd', | ||
| toolchain: jsToolchains |
Description:
On self-hosted runners toolchains.xml may survive multiple runs and unexpectedly grow as a result of the toolchains setup simply appending the JDK definition even if one with the same
typeandprovides.idalready exists.Restructuring the parsing step and filtering the potentially existing list of toolchain definitions prevents this and also fixes toolchain.xml files that already contain duplicates.
There is one open
TODOconcerning the recreation of thetoolchains-root node in the xml if an existing toolchains.xml was parsed. That could and potentially should be handled better and I am open to suggestions.Related issue:
#530
Check list: