Feature Request: support default environment variables/project properties

[joffrey-bion]

I feel like I'm always writing the same bintray { } closure over and over in many projects because they follow the same pattern.

Some values can have pretty reasonable defaults taken from the existing project configuration:

• pkg.name defaulting to the project's name
• pkg.desc defaulting to the project's description
• pkg.version.name defaulting to the project's version
• pkg.version.desc defaulting to the project's description

Also, everything that is not project-specific could (should?) be taken from the environment (either in gradle properties or environment variables). Environment variables are usually easier to use than gradle properties when configuring a CI/CD pipeline (they usually also have mechanisms to hide variables that contain secrets like API keys).

This is why I believe this plugin could define standard environment variables for some configuration values, which would enable smaller build files (and make people align on common names):

• user could fallback to the env variable BINTRAY_USER (possibly also allow a Gradle property)
• key could fallback to the env variable BINTRAY_KEY
• (debatable) pkg.repo could fallback to the env variable BINTRAY_REPOSITORY

Maybe I'm unaware that some of them actually already exist. If so, it would be nice to indicate it in the doc.

[Andre601]

I don't think this is a particularly good thing to have, as not everyone has env as BINTRAY_USER set and may use things like a gradle.properties file (which I did).

And some people might perhaps use GitHub Actions to automate their process of uploading things (or a CI server for that).

Tl;dr There are many variables to look for and just one specific use-case isn't really that big of a reason to implement something... I mean it's just System.getenv("name"), so what's so bad about it, especially when you can do a copy-paste?

My opinion tho.

[joffrey-bion]

I don't really get any of your points.

I don't think this is a particularly good thing to have, as not everyone has env as BINTRAY_USER set

Looking for an env variable if no setting was found can't do any harm though, so it doesn't change anything for people not defining this variable.

However it allows people who do use environment variables (e.g. for CI setup) to not have to configure this explicitly. Convention over configuration is one of Gradle's principles.

and may use things like a gradle.properties file (which I did)

In the first draft of my issue, I actually mentioned using gradle properties and then fall back to env variables if those are not found. That being said, sensitive information like the API key cannot and should not be placed in the project's gradle.properties (one can use the home properties, but that's not possible on the CI), so we're back to the same problem here.

And some people might perhaps use GitHub Actions to automate their process of uploading things (or a CI server for that).

How does that relate to the issue? I'm specifically speaking of simplifying the necessary Gradle config to enable CI/CD.

I mean it's just System.getenv("name"), so what's so bad about it, especially when you can do a copy-paste?

Well the point of having a Bintray Gradle plugin in the first place is to avoid copy pasting deployment code, so I find it reasonable to expect not to have to copy paste stuff from one project to another. Only project-specific things should appear in the build file, the rest should be in plugins.

I return the question, though: what is so bad about adding these defaults?

Also, what about all the other defaults, not even relying on env variables ?