SOLR-17619 add logchange plugin
https://issues.apache.org/jira/browse/SOLR-17619
See https://github.com/logchange/logchange/issues/397
run ./gradlew add for the wizard-style gradle task, or use our own simpler template ./gradlew generateChangeYaml
However it doesn't work because a conflict of Groovy transitive dependencies between this plugin and elsewhere in our build:
* What went wrong:
A problem occurred configuring root project 'solr-root'.
> Could not resolve all dependencies for configuration ':classpath'.
> Could not resolve org.apache.groovy:groovy:4.0.24.
Required by:
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-ant:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-cli-picocli:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-console:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-datetime:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-docgenerator:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-groovydoc:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-groovysh:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-jmx:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-json:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-jsr223:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-macro:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-nio:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-servlet:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-sql:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-swing:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-templates:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-test:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-test-junit5:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-xml:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-yaml:4.0.24
root project : > dev.logchange:dev.logchange.gradle.plugin:1.16.4 > org.apache.groovy:groovy-all:4.0.24 > org.apache.groovy:groovy-ant:4.0.24 > org.apache.groovy:groovy-bom:4.0.24
> Module 'org.apache.groovy:groovy' has been rejected:
Cannot select module with conflict on capability 'org.codehaus.groovy:groovy:4.0.24' also provided by [org.codehaus.groovy:groovy:3.0.9(runtime)]
@malliaridis I could really use your help on this aspect please. Build plugins seem special/different from a dependency standpoint.
@dsmiley Hello, check https://github.com/logchange/logchange/issues/397#issuecomment-2601012870
Marking the dependency to groovy-all as provided at the plugin level seems to be the best and easiest solution for solving this conflict. I am not sure how we could apply constraints to plugins that are loaded before the constraints block.
Thanks for addressing this @marwin1991 so quickly. 💪
I added a gradle task that generates a change YAML. This is tailored for our project, pre-fills some things, and is overall less of a hassle that logchange:add is.
I think the plugin's generation of the YAML is too problematic and has too little value-add. This draft PR includes a task "generateChangeYaml" that generates it; we should use that instead.
@malliaridis @dsmiley
Hello,
We can improve add task by defining in logchange-config.yml questions to skip and default value for skipped questions and command do execute something like
commands:
add:
questions:
fileName:
skip: true
value: "changelog/unreleased/${branchName}.yml"
variables:
- name: branchName
command: "git rev-parse --abbrev-ref HEAD"
But maybe adding new entry can be handle by your own custom task with needs suited for you? Generally its pure yml file and in 99% cases I use copy paste :)
I use add task (mvn mojo) for renovate post task to create entries in no interactive mode about dependency updates. For dependabot https://github.com/logchange/logchange/issues/429
Maybe the "add" feature of the logchange plugin is more useful to Maven. In Gradle, with native scripting, it was quite easy to tailor something specific to the project's needs.
I had some work from months ago trying to parse the entire CHANGES.txt to convert to yaml. At that time I tried feeding our perl script into Gemini to convert it to python, but it failed.
So today I decided to work with Claude Code to see what could be done. Together we wrote a python script dev-tools/scripts/changes2logchange.py which does advanced parsing of CHANGES.txt and spits out all the changelog folders with yaml in them and a release-date.txt file parsed from DOAP.
$ dev-tools/scripts/changes2logchange.py
Usage: changes2logchange.py <CHANGES.txt> [<output_dir>]
Arguments:
CHANGES.txt Path to the CHANGES.txt file to migrate
output_dir Directory to write changelog/ structure (default: ./changelog)
Running it yields
============================================================
Migration Summary:
Versions processed: 125
Entries migrated: 7033
Entries skipped: 0
Files created: 7033
Release dates written: 107
============================================================
Sample:
It's 7033 files. I suggest that we do not check in all of them, but instead use the "archive" feature of logchange to generate a single archive.md file for all versions to and including 9.9.0 :
logchange archive --version 9.9.0
It looks like this, and the command logchange generate will concatenate those automatically:
PS: These screenshots are made on main branch, that's why v9.9.1, v9.10.0 and v10.0.0 even exist.
Added a GitHub workflow that fails the PR if
- PR contains edit to
CHANGES.txt - Lack of a changelog yaml
See the workflow failing on this very PR...
- PR template mention
- Remove edit of CHANGES.txt from
addVersions.py(ran by RM) - The
addDepsToChanges.pyscript which adds SolrBot entries to CHANGES now adds them as YAML files - Ported
changes2html.pl(well, the HTML generating part) tochanges2html.pywhich reads CHANGELOG.md and outputs a html that looks exactly the same as the old format. Adapted gradle task to call the py script
Considered every mention of CHANGES.txt in the repo (except release notes etc), and updated each one. Mostly related to releaseWizard and scripts. This makes the releaseWizard ready for releasing with logchange workflow.
@anshumg As you have already started the wizard, you'll have a state.yaml file inside your .solr-releases/10.0.0/ folder. You could backup that file somewhere and try to run the wizard from this branch. I think it shuold be able to read the old yaml and write a new one. Some steps are removed and some new are added. Will try to dry-run the wizard just to see that there are no parse errors.
The updated wizard flow for syncing changes between branches is added as planned in hte JIRA issue, but by no means tested yet. We hope it will work to cherry-pick the commit after running logchangeRelease and logchangeGenerate.
Thanks @janhoy !