Allow for customization of project property source

[mcwhitak]

Currently a Gradle project property can be used as a source for a buildParameter but the property name is identical to the buildParameter path <group>.<property>.

This causes problems when overriding properties from the environment (via ORG_GRADLE_PROJECT_<propName>) as *nix systems cannot use . in environment variable names. Much like the fromEnvironment method accepts a source variable name, it would be great if we could override a "source property name" as well.

It could be via an propertyAlias function that would fall back on the alias property name if the original property was unset.

The primary use case for overriding properties via environment variables is in unified CICD systems where abstracting on top of Gradle lifecycle tasks may still require individual projects to override their own pipeline/environment variables.

[britter]

@mcwhitak why doesn't fromEnvironment work for you? Can you give a more comprehensive example for your use case?

[mcwhitak]

fromEnvironment implies something about the source of the property and Gradle properties can be set from a variety of sources (environment variables, CLI, project local gradle.properties files, gradle properties files in gradle user home, etc).

Hardcoding fromEnvironment would mean the build now had an opinion on the possible sources and we'd have to track two mechanisms to set that were not analogous. (ex: With Alias you can set the property via any existing Gradle means, with fromEnvironment now you have a different property name vs environment variable despite gradle properties being able to be set via environment variables). fromEnvironment is useful when the input is not Gradle aware (like say, getting the commit sha from a CICD pipeline).

An alternative to this that would solve the same issue for me would be the ability to customize the group delimiter

group("myGroup") {
  delimiter("_")
  string("myString")
}

Though I feel that's a bit less intuitive as then the parameter path buildParameters.myGroup.myString vs the property path myGroup_myString will feel more at odds. With the "alias" mechanism the original property is still valid there's just a second (or more) fallback entrypoint.

If this kind of thing goes against the goals you all had for the project I understand, this was just the issue I encountered when attempting to use it within my own projects (periods and *nix support)

EDIT: I'm realizing there's also a secondary motivator for me which is specific to my organization. We have a variety of spellings for our internal repo credential naming on Gradle properties (repo_user vs repoUser vs repo_username, repo.user, etc) over time opinions on these have changed but we have hundreds of repos so the alias mechanism would allow me to write out the various forms and ensure no matter what team/org a developer was coming from their setup would work correctly via build parameters.

[britter]

@mcwhitak thank you for providing more context! I still struggle to understand your concrete use case. Can you give a very concrete example of how you're injecting configuration into builds? Something like

"We use maven-publish to publish to our internal repository. Our developers set interalRepoUser and internalRepoPassword in their gradle.properties files in the user home. On CI we want to inject this values but we don't want to put them on the command line..."

This makes it much easier for us to reason about a good general solution.

Thank you so much! 🙏🏻

[britter]

Team decision

We understand the use case for setting a project property via ORG_GRADLE_PROJECT environment varibables and we see that this is currently not possible with build-parameters. We don't want to allow abitrary aliases for build parameters. So in order to address the ORG_GRADLE_PROJECT environment varibables use case, we are going to make build parameters also look up the lower_snake_base version of the property. This should cover your use case @mcwhitak. Can you please confirm?

[mcwhitak]

Ok I think that makes sense, I'll close my existing PR and make a new one if you are all open to outside contributions.

I still believe positioning buildParameters as a compile-safe reference to multiple property resolution mechanisms will eventually require the feature I've outlined here but I can totally understand not wanting to open that door (as it'd be impossible to close).

[britter]

@mcwhitak we're definitely open to outside contributions 👍🏻