Version Project

[johnthagen]

• Use frontend package.json as the common version for the application
  • Version number is statically compiled into the frontend using react-app env file
  • Version is displayed in the AppBar after logging in
• Add instructions to easily query the version using npm and node for use in CI and tagging of Docker images
  • npm run --silent version

---

This change is 

[johnthagen]

For potential future reference, it is then possible to extract the version from a running Docker container:

# Remove the ` before " when running on bash rather than powershell
> docker inspect --format '{{ index .Config.Labels `"com.github.sillsdev.thecombine.version`"}}' $(docker-compose ps -q backend)
0.1.0-alpha.0

Or a built image:

# Remove the ` before " when running on bash rather than powershell
> docker image inspect --format '{{ index .Config.Labels `"com.github.sillsdev.thecombine.version`"}}' thecombine_backend
0.1.0-alpha.0

[imnasnainaec]

Location in AppBar conflicts with #699

[johnthagen]

Latest UI looks like:

[lgtm-com]

This pull request introduces 1 alert when merging 66ad35c into adadeb4 - view on LGTM.com

new alerts:

• 1 for Unused variable, import, function or class

[jmgrady]

Reviewable status: 0 of 9 files reviewed, 1 unresolved discussion (waiting on @jmgrady and @johnthagen)

a discussion (no related file):
I have a question about the overall method. Why not use npm version to manage the version string? Is it because thecombine does not exist in the npm registry? We will need an easy method to lookup the version number so that the docker containers can be tagged with the correct version as well - it is my understanding that I cannot specify which image to pull by label, only by tag. That is why I am asking about npm version. It seems that the standard method for looking up the version would be:

npm view thecombine version

---

[johnthagen]

a discussion (no related file):

Previously, jmgrady (Jim Grady) wrote…

I have a question about the overall method. Why not use npm version to manage the version string? Is it because thecombine does not exist in the npm registry? We will need an easy method to lookup the version number so that the docker containers can be tagged with the correct version as well - it is my understanding that I cannot specify which image to pull by label, only by tag. That is why I am asking about npm version. It seems that the standard method for looking up the version would be:

npm view thecombine version

Can we assume that you will have npm installed anywhere you need to check the version? I was originally thinking you might want to check the version on a minimal Ubuntu VM (build runner, etc).

---

[jmgrady]

Reviewable status: 0 of 9 files reviewed, 1 unresolved discussion (waiting on @johnthagen)

a discussion (no related file):

Previously, johnthagen wrote…

Can we assume that you will have npm installed anywhere you need to check the version? I was originally thinking you might want to check the version on a minimal Ubuntu VM (build runner, etc).

As far as the build runners go, I think that we can define what we require to do the build. It is the servers where the software is installed that are more resource limited. I think that what Greg was trying to communicate was that once they deploy Kubernetes we can use that to spec out our build agents and we would not require more licenses because we have required another build agent configuration.

I asked mostly because I was trying to figure out how I would get the version number when tagging the images and I found npm version; it seems that it does a lot of what we want and it would be nice to use an existing tool. I don't know if there are limitations that won't work for us - you would know better than I. If npm version & npm view thecombine version don't fit the bill, then I would request that there is a straightforward way to lookup the version. Since it's JSON, a simple sed probably won't do the trick.

All that discussion aside, I just checked the build agent that we are currently using and it has Node.js 12:
node.js 12.16.1
node.js.npm 6.13.4
node.js.nvm yes

---

[johnthagen]

a discussion (no related file):

Previously, jmgrady (Jim Grady) wrote…

As far as the build runners go, I think that we can define what we require to do the build. It is the servers where the software is installed that are more resource limited. I think that what Greg was trying to communicate was that once they deploy Kubernetes we can use that to spec out our build agents and we would not require more licenses because we have required another build agent configuration.

I asked mostly because I was trying to figure out how I would get the version number when tagging the images and I found npm version; it seems that it does a lot of what we want and it would be nice to use an existing tool. I don't know if there are limitations that won't work for us - you would know better than I. If npm version & npm view thecombine version don't fit the bill, then I would request that there is a straightforward way to lookup the version. Since it's JSON, a simple sed probably won't do the trick.

All that discussion aside, I just checked the build agent that we are currently using and it has Node.js 12:
node.js 12.16.1
node.js.npm 6.13.4
node.js.nvm yes

Yes, I agree it will be simpler to put the version only in package.json and provide a convenient CLI command (npm run version) that the CI can use to query for the current version of the project. This can be used to tag the Docker images when built in CI.

I've removed the Dockefile LABELs. I originally was hoping there was an easy way to build the version into the image and have Docker use that when tagging, but it unfortunately doesn't look like that is something that is supported (even less so in Compose vs base Docker).

The new solution should make it easy to get the version in CI as long as the build system has npm and Node, which seems like a reasonable requirement for this project.

---

[jmgrady]

Reviewed 3 of 9 files at r1, 1 of 2 files at r2, 2 of 5 files at r5.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @jmgrady and @johnthagen)

---

README.md, line 242 at r6 (raw file):

npm run --silent version

When I run this command I get:

sh: 1: Syntax error: "(" unexpected

(running in a bash shell on Ubuntu 18.04).

[jmgrady]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @jmgrady and @johnthagen)

---

package.json, line 29 at r6 (raw file):

   "version": "node -e console.log(require('./package.json').version);"

When I run this command I get: sh: 1: Syntax error: "(" unexpected
(running in a bash shell on Ubuntu 18.04).
I have moved this command to a printVersion.js and changed this line to:

    "version": "node printVersion.js"

I will commit the change for your review after I publish this comment.

[johnthagen]

---

package.json, line 29 at r6 (raw file):

Previously, jmgrady (Jim Grady) wrote…

   "version": "node -e console.log(require('./package.json').version);"

When I run this command I get: sh: 1: Syntax error: "(" unexpected
(running in a bash shell on Ubuntu 18.04).
I have moved this command to a printVersion.js and changed this line to:

    "version": "node printVersion.js"

I will commit the change for your review after I publish this comment.

LGTM.

We generally use TypeScript for these kinds of scripts, but given this is so incredibly simple, just a JS file seems appropriate.

[johnthagen]

---

README.md, line 242 at r6 (raw file):

Previously, jmgrady (Jim Grady) wrote…

npm run --silent version

When I run this command I get:

sh: 1: Syntax error: "(" unexpected

(running in a bash shell on Ubuntu 18.04).

Done

[imnasnainaec]

Could we also add a version badge to our Readme?

[imnasnainaec]

Reviewed 3 of 3 files at r7, 1 of 1 files at r8.
Reviewable status: complete! all files reviewed, all discussions resolved

[johnthagen]

Could we also add a version badge to our Readme?

@imnasnainaec Done.

[jmgrady]

Reviewed 1 of 1 files at r9.
Reviewable status: complete! all files reviewed, all discussions resolved