Provide Spring Cloud version via some utility method

[Sarvesh-D]

As per gitter communication, please provide some utility method (something similar to SpringBootVersion.getVersion()) to provide the version of Spring Cloud used by the target application. This information can be used by the client applications to visualize their application's cloud version.
P.S: it would be nice to include the stability of cloud version like, example: Finchley.RELEASE, Finchley.SR1.

[edeandrea]

I would even go so far as to add to this the ability for spring-cloud to provide that information as an InfoContributor as well, so that it shows up in the /info actuator endpoint.

[Sarvesh-D]

In that case, can spring boot version also be included in InfoContributor by default?

[edeandrea]

As nice as it would be, I don't think that capability is a spring-cloud concern. You'd probably have to raise that in the spring-boot issue tracker.

[snicoll]

It would be nice to, temporarily at least, ignore this comment as we're having a similar conversation in Spring Boot.

[ryanjbaxter]

I am still not sure I understand the use case for the application to know about what version of Boot or Cloud that is being used.

[edeandrea]

Mostly for compliance/auditing/monitoring reasons. Organizations have tools internally (Spring Boot Admin console, etc) which can audit applications to make sure they are running with certain versions of things. It would be nice to be able to audit a running application to gather this information without having to trace it back to a build version, then back to Artifactory and looking at the pom to find out.

[snicoll]

It would be nice to be able to audit a running application to gather this information without having to trace it back to a build version, then back to Artifactory and looking at the pom to find out.

Can't you use the build-info maven/gradle plugin for this? You can add arbitrary dependencies in there that can use the API of your build. Here is an example with Maven.

[edeandrea]

Yes we could but then we'd have to do that in all 1,000+ applications within our organization. If the spring-boot gradle plugin did it then that would solve it as well. Otherwise we'd have to build our own "wrapper" Gradle plugin that did it.

[snicoll]

If the spring-boot gradle plugin did it then that would solve it as well.

That feature is obviously supported in Gradle as well. As for configuring your 1000+ projects, I'd argue it is a separate problem. And I am not against adding SpringCloudVersion#getVersion() either.

[edeandrea]

Yes the feature is supported in Gradle and organizations could certainly do something on their own to use that. Personally within my organization we already have a wrapper plugin where we could do this pretty easily for all applications that use our wrapper plugin. Our internal framework starters control the spring-cloud-dependencies BOM version automatically anyways, so application teams here don't even have to do it for themselves. So it wouldn't really be a big deal for us to go that route.

I'm sure not all organizations have that luxury though.

It would be nice though to be able to get something "out-of-the-box" where its just "there". Maybe exposing a SpringCloudVersion#getVersion() is enough and then implementors can decide what to do with it from there. That might be a good trade-off between framework & implementation.

[ryanjbaxter]

I would also think it would be possible to scan you source control org and find the projects that are using an older boot or cloud version

[edeandrea]

I would also think it would be possible to scan you source control org and find the projects that are using an older boot or cloud version

Yes we could, but source control has more things than are currently running in production (different problem I know). But it would be nice to be able to look at what is actually running in production/qa/dev/etc in real time.

[wilkinsona]

FYI, we have decided not the expose the Spring Boot version via the /info endpoint out of the box due to security concerns. SpringBootVersion and SimpleInfoContributor can be used to opt in.

[Sarvesh-D]

Ok, if it poses security threats to have version in /info url then its fine, but atleast there is method that provides that version. I would love to see such method in Spring Cloud, and again as @edeandrea said, the implementers can decide if they wan't to expose that version info or not..

[spencergibb]

I've not looked at it, but the implementation might be tricky since the release train is defined somewhere else (spring-cloud-release).

[spencergibb]

After a bit of interest because of #489 I still don't know how to do this. The release train (Finchley.X, Greenwich.X, etc...) is only defined in a BOM (Bill of Materials) and that is in a separate project. Individual projects (like this one) don't know what release train they are in. Indeed a particular version may be in multiple trains if there were no changes (Finchley.RELEASE and Finchley.SR1).

[SoftwareKing]

but is too lowï¼?

[SoftwareKing]

Can you add version information to spring-cloud-commons in a similar SpringBootVersion.getVersion() way when it is released?

[edeandrea]

At build time of spring-cloud-commons could you gather the release train info and store it in the jar's manifest (or some other file within the jar) which could then be read at runtime? Granted with this approach if someone override the jar version of spring-cloud-commons then it could reflect a different version of spring-cloud BOM.

[spencergibb]

We have no knowledge of the release train at build time and as I said before, one version can belong to multiple trains, so that won't work

[spencergibb]

We now have a webservice that can be called that can give you the compatible spring cloud release train. I'll let @ryanjbaxter put a url to that. If we were to do this, it would be during the release of the release train. Snapshots would not have this information. Also, if a user overrides the version of spring cloud commons, it would report a different release train than what is in use.

[ryanjbaxter]

More information on the API can be found here
https://spring-cloud-info.cfapps.io/docs/spring-cloud-info.html#_spring_cloud_version_given_spring_boot_version

Note this is very early stages, so I fully expect everything about the above service to change, but the intention is to alleviate these type of questions so any feedback is welcome.

I also just realized that the version returned by the above API may not be what is used by the app. The API above will always return the latest compatible Spring Cloud release for the given Boot version, however your app might be using a prior release so it may not be exactly what you are looking for.