Support overriding the version of the CLI extractors to use

[markrekveld]

Is your feature request related to a problem? Please describe.
It's impossible to test PRs for extractors without also building a custom CLI and using this. But then, what are you testing? Any issue during the CLI build to validate and test the extractor build makes it harder to do a proper job.

Take this case:
I found a (in my eyes) bug in the extractor implementation for Maven. It introduces a 'dummy' repository but this is causing numerous issues with Maven plugins that cannot take this kind of repository into account.

So I opened a PR in an attempt to resolve this: jfrog/build-info#683
But this introduced a bug and needed to be reverted.
This is not only annoying for me to have to revisit the PR again, but also other customers affected by the introduced bug.
It was easy to resolve and a new PR was opened to address the bug introduced jfrog/build-info#715

I'm confident that the bug would not have been introduced if it was easier to test the custom version of the extractor.

Describe the solution you'd like to see
I would like to be able to override the version of the extractor used during Maven builds so I can use or test a custom version of the extractor.

Currently you can provide a different remote server to download the extractor from, but the version is hardcoded at https://github.com/jfrog/build-info-go/blob/a6ed2e89a5bf16feff10be3333c5f69821b0b903/build/maven.go#LL21C29-L21C29
But it would be great if this version can be overridden by an environment variable just like the remote server can be overridden.

Describe alternatives you've considered
The only alternative is to also build a custom CLI version to test the custom extractor version, which is not really an alternative if you ask me.

Additional context
See also opened support ticket

[eyalbe4]

Hi @markrekveld,
First of all - thanks a lot for being active and helping us improve the code. This is highly appreciated!
As for your request, we do not believe that the approach of overriding the versions of internal dependencies is the right approach, because this may lead to compatibility issues. For development purposes, you can always modify the code to use a specific version.

[markrekveld]

Hi @eyalbe4

Thanks for your reply.

I'm a but lost. The CLI is hardcoded to a specific version of the build info extractor. How can I use the CLI with a different version of the extractor to test a pull request like the one I linked?

Can you please take me trough the steps how I would be able to test a code change like the linked PR on a CI system like JFrog Pipelines where you only have the option to select version 1 or 2 of the JFrog CLI?

Cheers,
Mark

[talarian1]

Hi @markrekveld,

Thanks again for your contribution and willingness to improve our products :).
Based on my understanding of your requirements, it seems that the current implementation is sufficient. Here are the steps you can follow:

1. For local testing, please replace the existing extractor jar with the new jar you have created. The JFrog CLI will utilize the extractor located in ~/.jfrog/dependencies/gradle/[VERSION].

2. If you would like to replicate the same behavior in your CI environment, you will need to upload the new extractor to the custom remote server that you have configured to download the extractor from. Make sure to use the same name and version as the current extractor version.

Please let me know If you have any further questions.

[markrekveld]

Hi @talarian1

Thanks for your explainer, it is doable and workable hijacking the extractor version.
But would consider this a workaround. I still think being able to override the version would be a better solution.

I'll take some time to see if I can get the JFrog Pipelines platform to accept this workaround.

Cheers,
Mark

[markrekveld]

Hi @talarian1 @eyalbe4

I just tried to override the extractor version used by the CLI , but there is no way to predict the version of the maven extractor that CLI will use when running on JFrog Pipelines. So implementing a way to preload the extractor is not an option.

This only leaves implementing a "custom" server to download the extractor from. This "server" would need to capture all the requests for the extractor and then return a different version then the one being requested.

This seams to me a lot of work where a simple environment property defining the version to download would fix the issue.
Any chance of reconsidering supporting the overriding of the version that is downloaded?

[markrekveld]

I implemented my attempt in #168 please give it a review

[markrekveld]

Here is another example to support overriding the extractor version used, jfrog/build-info#738

[markrekveld]

@talarian1 @eyalbe4 do you see this issue and/or my implementations being accepted any time?