neoforged / gradleutils Goto Github PK

I have been using GradleUtils for a while now to generate me plain text and markdown changelog files, this all works great until it comes across a commit which has multiple lines/bullet points to it, the plain text formats fine but markdown renders all lines as 1 continous line, making it hard to distinguish between them all.

As you can see by the provided image, the plain text on the left, splits both lines up correctly,
but the markdown render is just removing the empty whitespace between the 2 lines making it hard to see the 2 different points.

A potential fix I would suggest would be changing markdown from aligning the multi lines, to being a indented dash ( -) as markdown would then render these as each there own sub bullet points.

Currently, GradleUtils uses an awkward system to self-version itself. It holds source files in buildSrc, which is referenced by the buildscript for version calculation and changelog generation; the buildscript then copies over these source files to the root project source folder, ignored by git to avoid being committed.

I propose GradleUtils should itself use manual/maintainer-controlled versioning, instead of relying on this awkward system of copying source files from subproject to root project.

There are multiple reasons as to why this should be done:

• GradleUtils would be the sole project that uses manual versioning in NeoForged. All other projects would rely in GradleUtils for their versioning and changelog generation. As GradleUtils is likely infrequently updated, the burden of maintainer-controlled versioning won't be too much of a hassle over the long term.
• This gets rid of that awkward/cursed source copying system, simplying the project structure significantly.
• This gives us the flexibility to collate many changes which would each break the public API as one release, rather than being staggered across multiple releases (since each commit/PR would be built and published as its own release).

This would mean that changelogs wouldn't be auto-generated anymore (unless its automated via another way), but I find that acceptable due to two reasons: few if not none reads the changelog for GradleUtils, and changelogs would still be part of the GitHub release information.

Personally, I find this the only good option to proceed with GradleUtils for future development.

An alternative would be to use a previously-published version of GradleUtils in this project, pinned to an exact version.

The configuration cache is a feature which improves build performance by caching the results of the configuration phase, for reuse in future builds. To accomplish its goals, the configuration cache imposes certain limitations on what can be done during the configuration phase, so it can keep track of all the state of the configuration phase.

One of these limitations is a prohibition on running external processes. Running external processes should be done either as a task action (i.e. deferring to the execution phase), or through configuration-cache-compatible APIs such as ProviderFactory#exec or inside a ValueSource with an injected ExecOperations service.

Unfortunately, GradleUtils currently runs afoul of this limitation, because of JGit. JGit executes the git command (using Java's ProcessBuilder) to gather information about the system-wide git config.

After some investigation, it seems not possible to specifically replace the code in JGit which executes those commands to use the Gradle APIs mentioned above. Therefore, we have to wrap invocations to JGit -- specifically, those which construct a new Repository directly or indirectly -- inside of a ValueSource.

See https://discord.com/channels/313125603924639766/1136320550168436798/1161044932186865684. Several NeoForged projects, including Access transformers, include the build time as a timestamp in the built manifest. This isn't great. A better solution would be to include the timestamp and hash of the current commit - and having a method in the gradleutils extension for that is probably a good idea