Expose Version, Git and build info in a new controller (CIRSUP-2014)

[StanMarkov]

• add new maven plugin that helps expose the git and build information.

• create new properties file (iceversion.properties) that contains the ice-version.

• Modify beans.xml to allow loading the new properties files (iceversion.properties and git.properties).

• Configure a VersionData bean that holds all the info.

• Inject VersionData into VersionResource controller (opencds-rest-service)

• Inject VersionData into RequestProcessorService.

• RequestProcessorService sets iceVersion on the EvaluationRequestDataItem.

• ICEDecisionEngineDSS7EvaluationAdapter will set the iceVersion via set global command in the context.

• Comment out setting the iceVersion from the org.cdsframework^ICE^1.0.0.drl file, now ICEDecisionEngineDSS7EvaluationAdapter sets the version.

• Introduce iceversion.properties in the opencds-ice-service to store the version.

• Change beans.xml to read git.properties and iceversion.properties into the context properties.

• Create a new map bean that contains the version, git and build information.

• Init the VersionResource controller with the map bean. Everything in the map will be returned by the controller.

• Create ICEVersionUtil.java which will allow static access to the ice version.

• Use spring to set the version map bean into ICEVersionUtil.java.

• Add git version maven plugin to the opencds-ice-service pom.xml to produce git.properties.

• Modify the opencds-ice-service so it carries properties files from the src folder to the output.

• Changed ICEDecisionEngineDSS7EvaluationAdapter to get the iceVersion from ICEVersionUtil.java

[#CIRSUP-2014]

[StanMarkov]

@darylbc @nicolary please take a look at this commit for exposing the version/git/build information.

In a nutshell - the idea is the version string is now stored in iceversion.properties and we read that in VersionData. VersionData is then shared with the VersionResource controller to expose it via http. On the rule processing side, VersionData is injected into RequestProcessorService and set on each EvaluationRequestDataItem. From there ICEDecisionEngineDSS7EvaluationAdapter sets it in the global context for the drl processing. I did comment out the line in org.cdsframework^ICE^1.0.0.drl that sets the version.

I've tested the rest/http part, but no idea how to test the rules processing. If the implementation looks good to you, we should do a test to make sure the version gets propagated properly when running the rules.

Depends on this other pull request https://github.com/cdsframework/opencds-rest-service/pull/5 that has the rest controller impl.

Sample output of the rest controller.

GET http://localhost:8080/opencds-decision-support-service/version

HTTP/1.1 200 
Date: Wed, 13 Oct 2021 00:32:41 GMT
Content-Type: application/json
Content-Length: 91
Keep-Alive: timeout=20
Connection: keep-alive

{
  "iceVersion": "ICE_1.30.1",
  "gitCommitSha": "6833826",
  "buildDate": "2021-10-12T15:48:00-0700"
}

Response code: 200; Time: 595ms; Content length: 91 bytes

[StanMarkov]

@darylbc @nicolary another try :)

I did shift all the changes to the ice3 project. The only remaining changes in the opencds project are to beans.xml.

Approach I took is to store iceversion.properties with the source of the opencds-ice-service, and also moved the git commit maven plugin to that project. The file it generates (git.properties) is put into the target/classes folder in the same location as iceversion.properties.

beans.xml reads those property files and creates a hash map with the data we want to expose. The map is passed to the VersionResource controller, and also ICEVersionUtil class to be used by the ICEDecisionEngineDSS7EvaluationAdapter .

One thing I felt was iffy is how I init the ICEVersionUtil from the spring context, instead of just reading iceversion.properties directly, but had two reasons:

• It keeps reading of the properties file to a single place (beans.xml)
• It allows us to expand ICEVersionUtil relatively easy and use additional values like commit sha/build datetime, that are already in the map, if needed, without having to also read git.properties separately.

If you feel there is a better approach, I'm open to changes 👍

[darylbc]

Thanks @StanMarkov. Do you have a sample http request, so that I can try this out?

[darylbc]

@StanMarkov - Nevermind. I see it in your description above :)

[darylbc]

Looks good. Thanks!