Pass buildNumber and branch to DSpace Docker builds

[terrywbrady]

When the "dspace version" command is run, "SCM revision" and "SCM branch" are set. These values are not getting set in our Docker builds. I wonder if there is a way to pass these values through environment variables. Do you know what mechanism grabs these values?

Kim Shepherd [12:56 PM]
@terrywbrady the file that holds the vars is dspace-api/src/main/resources/scm.properties

branch = ${scmBranch}```
and it seems to be maven that populates it, as the `target` version in dspace-api/target/classes/scm.properties looks like this
```revision = 929312d7e8728d33d3425e2b106c444444ea0468
branch = DS-4136_oai_import_master```
so, not sure how docker is missing out.. the maven build is fairly straight forward isn't it?
(you can see the full class at `org.dspace.app.util.Version`

Mark Wood [1:13 PM]
Yes, Maven creates that file for us.  The resource plugin fills in values from the effective POM while copying the template over to target.  It's not easy to see, but see dspace-api/pom.xml (edited) 
Likewise Ant write its version into 'ant.properties'.

Kim Shepherd [1:54 PM]
hm, interestingly, though  my docker-dev-compose instance works ok (it's an old one) for `dspace version`, it lists each webapp in Applications at least 10 times.. i wonder if there's some caching in the UtilServiceFactory stuff, or some filtering/deduplication needed in the results for that...

Mark Wood [1:56 PM]
That's an old problem that I need to fix someday.  The duplicates for webapp X *should* all be deleted when X starts, but for some reason they persist.
https://jira.duraspace.org/browse/DS-3000

Terry Brady [2:06 PM]
Since the published images are built on Dockerhub, those values are probably not set.  I will add an issue to our Docker project to find a way to set these values.

Based on this report, I would expect a locally built instance to possibly have the branch.