-
Notifications
You must be signed in to change notification settings - Fork 1
Conversation
echo "property1=value1" >> gradle.properties | ||
echo "property2=value2" >> gradle.properties | ||
echo "property3=${ENV_VAR}" >> gradle.properties |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if I understand correctly we write these values to a local file before we run ingestion?
Does that mean these values will then pop up as a suggested code change on every PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think that we were going to suggesting it as a code change on every PR, but definitely gonna add it to the LST... I'm thinking on adding it to the local list of git ignored files like we do for other files (like ingest.xml for maven), but I'm not really comfortable adding it there, because then we are not going to ingest any gradle.properties file ever into LSTs if they were already existing...
Any suggestion here? In theory there is a mechanism to add gradle properties via env vars, but it does not support properties with dots really well....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know the specifics about that environment variable handling, but I'd say that's preferred over serializing values only there for ingestion; that could lead to confusing issues if those values do show up in diffs or commits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To handle the dotted case, you could just pass the properties as JVM arguments as was done here:
https://github.com/moderneinc/moderne-cli/commit/4bff46681ff421c9788cc7a029e309ecda888827
Dots in the environment variable also works just fine when using something like ORG_GRADLE_PROJECT_my.prop
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could probably use --additional-build-args
on mod-cli to have those passed to gradle, because I cannot find a way to set env vars with dots on a bash shell... Maybe on windows it's possible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about using the --additional-build-args
and just passing them all as -P<key>=<value>
pairs? Then you don't have to do anything funny with the variable names at all as a bonus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Explored this possibility, but they end up being serialized on build.log. Most likely solution right now is going to be change the properties to not have dots and use env vars with ORG_GRADLE_PROJECT_ prefix
Closing this PR as it is superseded by #61 |
What's changed?
Added capability to set gradle properties
What's your motivation?
we need gradle properties to configure moderne repos build
Anyone you would like to review specifically?
@timtebeek
Checklist
./gradlew licenseFormat