Using the library silently upgrades local configuration to version 3, which makes it unusable for "jfrog" command about jfrog-cli-core

[eyalbe4]

@jhinrichsen,
I understand that you have multiple pipelines, which use different versions of JFrog CLI and all of these pipelines use the same JFrog CLI configuration.
To get this issue resolved, do you see an issue with upgrading JFrog CLI to the latest version for all pipelines?
We haven't considered a case where different versions of JFrog CLI's will use the same config directory. The idea was to upgrade the configuration, with the requirements of the new release. The version property inside the config is used to determine whether the config needs to be upgraded or not.
Can you please share with us more info about the reason why multiple versions of JFrog CLI are used? This may help us better understand the problem and consider possible solutions.
Thanks.

[jhinrichsen]

No, if a pipelines uses the JFrog CLI the one and only version is 1.36.0. However, the first pipeline uses jfrog-cli-core library instead of jfrog executable, which updates the config and makes it unusable for jfrog executable.

[jhinrichsen]

Not sure but I guess the update is part of https://pkg.go.dev/github.com/jfrog/jfrog-cli-core/utils/config#GetDefaultArtifactoryConf. At least the documentation does not suggest "oh, and as a side effect, it will rewrite your local config to V3 which effectively renders jfrog executable useless" ;-)

[eyalbe4]

@jhinrichsen,
When you say "the first pipeline uses jfrog-cli-core library" - do you know how the pipeline uses the jfrog-cli-core library? Is it through another go application which depends on jfrog-cli-core? Is this another CLI?

[jhinrichsen]

Yes, the Go library jfrog-cli-core is used by an inhouse Go program other than the JFrog CLI executable.

Compared to git, trivial pipelines use the commandline executable 'git', while more advanced requirements that require custom logic use libgit2.

[eyalbe4]

I see @jhinrichsen.

I guess that for future config upgrades, we can design the config migration mechanism to support multiple config versions, by simply keeping a copy of the old config, so that older versions can use it.
This may mean though that adding a server to the old config, will not be reflected in the new config. Let me know what you think about adopting this approach,

In the meantime, to resolve the issue, will you be able to upgrade the version of JFrog CLI to the latest, in all pipelines?

[jhinrichsen]

An upgrade of jfrog executable resolves the issue.

[eyalbe4]

I'm glad to hear this @jhinrichsen! Thanks for the update.
We made the config upgrade backward compatible, by copying the config to a new file, which is used by the new version only.
Feel free to close this issue.