Skip to content

Conversation

mateuszkwiecinski
Copy link
Contributor

@mateuszkwiecinski mateuszkwiecinski commented Jul 14, 2025

Description

This PR introduces the following set of behavior changes:

  • signing config has been extracted from shadowJarExecutable task into signShadowJarExecutable to make it compatible with configuration cache
    • running shadowJarExecutable automatically runs shadowJarExecutableChecksum so the user-facing behavior is the same.
Before After
image image
Before After
image image
  • Tasks expose very explicit inputs&outputs rather than passing parent directory reference around. That way running task multuple times (with --rerun flag results in a deterministic behavior)

Checklist

Before submitting the PR, please check following (checks which are not relevant may be ignored):

  • Commit message are well written. In addition to a short title, the commit message also explain why a change is made.
  • At least one commit message contains a reference Closes #<xxx> or Fixes #<xxx> (replace<xxx> with issue number)
  • Tests are added
  • KtLint format has been applied on source code itself and violations are fixed
  • PR title is short and clear (it is used as description in the release changelog)
  • PR description added (background information)

Documentation is updated. See difference between snapshot and release documentation

  • Snapshot documentation in case documentation is to be released together with a code change
  • Release documentation in case documentation is related to a released version of ktlint and has to be published as soon as the change is merged to master

@mateuszkwiecinski mateuszkwiecinski force-pushed the fix_configuration_cache_compatibility branch 2 times, most recently from 2f43d90 to b5fb3af Compare July 14, 2025 23:10
windowsBatchScriptSource.set(layout.projectDirectory.file("src/main/scripts/ktlint.bat"))
outputDirectory.set(ktlintOutputRoot)

finalizedBy("signShadowJarExecutable", "shadowJarExecutableChecksum")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the configuration-cache compatibility fix. Previously the build tried to sign ktlint executable file as a part of shadowJarExecutable invocation, now it'll run after shadowJarExecutable completes, after the executable file has actually been created

val outputDirectoryPath =
layout.buildDirectory
.dir("run")
.archiveFile
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shadowJar exposes a named output, so I updated the code so it's used here as well rather than iterating over outputs manually

Copy link
Contributor Author

@mateuszkwiecinski mateuszkwiecinski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is the build failed because it tries to sign the artifacts (since the project version set to stable one), but it doesn't have access to singing keys given the PR is opened from a fork.

@paul-dingemans
Copy link
Collaborator

  • Please let me know if checksums aren't meant to be published I'll then propose to remove all the checksum related code.

Looking at the commits in the PR #1952 it is clear that the change was initiated by @Goooler. At April 20, 2023 @shashachu reverted the signing, followed by the release of version 0.49.0 on April 21, 2023. So it looks like that during release of 0.49.0 a blocking problem occurred, which was resolved by partially reverting the signing. To me this sounds that the signing was accidentally removed to unblock the release.

Having said that, we can argue about the value of having the md5 files being published. No one has complained about a regression since the md5 files are missing.

Does any of you have an argument in favor, or against re-adding the md5 functionality?

@mateuszkwiecinski
Copy link
Contributor Author

Artifacts available on Maven central have their own authenticity certification: signature, hash, so from my perspective those hashes are useful only for people downloading artifacts directly from github release page (does that include homebrew? I have close to zero knowledge how homebrew works 😬 )

At the same time nothing prevents an attacker to swap both executable and hash file (releases can be edited, new artifact files can be uploaded), so I don't know if the checksum comes with any safety guarantee 😅

tl;dr I don't think these extra checksums bring any value, especialy they are gone for >2 years 😅

@paul-dingemans
Copy link
Collaborator

so from my perspective those hashes are useful only for people downloading artifacts directly from github release page (does that include homebrew? I have close to zero knowledge how homebrew works 😬 )

Github release pahe publishes the SHA256 for this:
Screenshot 2025-07-15 at 21 09 08

Also in ktlint documentation it is explained how to verify the downloaded file.

tl;dr I don't think these extra checksums bring any value, especialy they are gone for >2 years 😅

Agree. @Goooler, @shashachu, what do you think?

@mateuszkwiecinski
Copy link
Contributor Author

mateuszkwiecinski commented Jul 15, 2025

Github release pahe publishes the SHA256 for this:

:TIL:, looks like relatively new feature? None of the previous releases had such metadata attached 👀

@mateuszkwiecinski mateuszkwiecinski force-pushed the fix_configuration_cache_compatibility branch from b5fb3af to af74d3a Compare July 16, 2025 08:15
@mateuszkwiecinski mateuszkwiecinski changed the title Update signing config, restore MD5 checksums, fix configuration-cache compatibility Update signing config, fix configuration-cache compatibility Jul 16, 2025
@mateuszkwiecinski mateuszkwiecinski force-pushed the fix_configuration_cache_compatibility branch from af74d3a to 9ec1ec6 Compare July 16, 2025 08:48
// Avoid setting empty strings as signing keys. This avoids breaking the build when PR is opened from a fork.
// Also, due to https://github.com/gradle/gradle/issues/18477 signing tasks try to prematurely access the signatory.
// This also improves error messages if something's misconfigured
useInMemoryPgpKeys(signingKeyId, signingKey, signingPassword)
Copy link
Contributor Author

@mateuszkwiecinski mateuszkwiecinski Jul 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new task I added (signShadowJarExecutable) gets created eagerly, tries to access the signatory and fails if the signing info contains empty string (not nulls)

As a workaround I'm proposing to configure the signing conditionally. This solves the misbehavior of the Sign task, but also should not fail PRs from froks created during release (the isRequired property is not the only input that determines if the signing tasks should run - link)

@mateuszkwiecinski
Copy link
Contributor Author

The checksum calculating code has been removed in 9ec1ec6

@Goooler
Copy link
Contributor

Goooler commented Jul 16, 2025

I don't like this idea, I don't like #3047 too.

@mateuszkwiecinski
Copy link
Contributor Author

I don't like this idea, I don't like #3047 too.

@Goooler You have to be more specific 😄 I fail to find how such feedback would be actionable 😅

Copy link
Collaborator

@paul-dingemans paul-dingemans left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding of this part of the build is increased a lot. I have a lot of naming things that might improve the code even more. Please have a look at the suggestions.

@paul-dingemans paul-dingemans merged commit 2d7a94a into pinterest:master Jul 19, 2025
12 checks passed
@mateuszkwiecinski
Copy link
Contributor Author

Thanks for clearing that up in #3078 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants