Skip to content

feat(maven): Remove Gradle properties after publishing - #276

Merged
iker-barriocanal merged 7 commits into
masterfrom
iker/ref/maven-rm-gradle-props
Aug 18, 2021
Merged

feat(maven): Remove Gradle properties after publishing#276
iker-barriocanal merged 7 commits into
masterfrom
iker/ref/maven-rm-gradle-props

Conversation

@iker-barriocanal

Copy link
Copy Markdown
Contributor

Removing the gradle.properties after running the maven target may prevent exposing it, which contains the OSSRH credentials (see #272). There also are minor changes to address some feedback in #270.

@iker-barriocanal
iker-barriocanal requested a review from BYK August 17, 2021 11:16
@iker-barriocanal iker-barriocanal self-assigned this Aug 17, 2021
Comment thread src/targets/maven.ts Outdated
Comment thread src/targets/maven.ts
*/
public deleteUserGradlePropsFile(): Promise<void> {
return fsPromises.unlink(
join(this.getGradleHomeDir(), GRADLE_PROPERTIES_FILENAME)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Who creates this file? If it is the closeAndReleaseRepository script, then shouldn't this be its responsibility (to remove the file I mean)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It's created by the target itself (by the method right above it)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Then at this point, I'd convert this into something like withTempDir with auto-clean up even in case of exceptions for safety. This is much like a Python Context Manager

@BYK BYK left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Pushing back for even safer code 馃榾

Comment thread src/targets/__tests__/maven.test.ts
Comment thread src/targets/maven.ts
*/
public deleteUserGradlePropsFile(): Promise<void> {
return fsPromises.unlink(
join(this.getGradleHomeDir(), GRADLE_PROPERTIES_FILENAME)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Then at this point, I'd convert this into something like withTempDir with auto-clean up even in case of exceptions for safety. This is much like a Python Context Manager

@BYK BYK left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Postponing the context manager idea to a follow-up. Looks good as it is, thanks a lot!

@iker-barriocanal
iker-barriocanal merged commit 55532a4 into master Aug 18, 2021
@iker-barriocanal
iker-barriocanal deleted the iker/ref/maven-rm-gradle-props branch August 18, 2021 11:36
@marandaneto

marandaneto commented Aug 19, 2021

Copy link
Copy Markdown
Contributor

@iker-barriocanal my suggestion was not really to remove the file, but to erase the content of the written properties, this is a global file that has also users configuration, if you delete the file, I will have to copy/paste all my user configuration again

@BYK

BYK commented Aug 19, 2021

Copy link
Copy Markdown
Member

@marandaneto I think we can incorporate this feedback into the planned follow-up: use a context manager-like function which keeps a snapshot of the old file around and restores it back once the operation finishes.

@iker-barriocanal

Copy link
Copy Markdown
Contributor Author

@marandaneto if that user configuration is relevant for this target, the target itself should be able to get it in some way. When this gets moved to GHA anything that the target isn't able to get won't be in that config file.

@marandaneto

Copy link
Copy Markdown
Contributor

@iker-barriocanal no, its not relevant for the target, but the file is a global configuration file for Gradle itself, so it could be from different projects etc, eg:

a=1
b=2
c=3

now you add
mavenCentralUsername=user
mavenCentralPassword=pass

so:

a=1
b=2
c=3
mavenCentralUsername=user
mavenCentralPassword=pass

when you delete the file, my projects in need of a, b and c fails.

@BYK suggestion of keeping a snapshot of the file is great, restoring to the previous state, I'd rather say it's a severe bug.

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