Dev/deploy

[it-hms]

This PR adds a github action to upload production artifacts to S3. This allows for a easier access to artifacts that are commonly downloaded.

[alexjhawk]

@it-hms I think this is a significant enough change/addition to repository functionality to add a second reviewer.

[it-hms]

This functionality should also be made generic and installed within our starter project repository: https://github.com/hms-networks/sc-java-maven-starter-project.

The difficulty with a generic solution is that each project may have different names for the .jar file, the configuration file(s) and may or may not have jvmrun files. These commits do have project specific regex checks for files names that are narrowly defined and would not work with any other repo. Also there are rules for what is considered a complete release; the current code requires a .jar, a jvm, and a configuration file to be considered for upload. Also this commit is only compatible with a semantic versioning system that is y.x.v.

To make generic, we would have to enforce naming rules for release assets ( or better release actions). Additionally, we would have to provide a way to have a flexible way of defining the artifacts that should be uploaded.

[alexjhawk]

This functionality should also be made generic and installed within our starter project repository: https://github.com/hms-networks/sc-java-maven-starter-project.

The difficulty with a generic solution is that each project may have different names for the .jar file, the configuration file(s) and may or may not have jvmrun files. These commits do have project specific regex checks for files names that are narrowly defined and would not work with any other repo. Also there are rules for what is considered a complete release; the current code requires a .jar, a jvm, and a configuration file to be considered for upload. Also this commit is only compatible with a semantic versioning system that is y.x.v.

To make generic, we would have to enforce naming rules for release assets ( or better release actions). Additionally, we would have to provide a way to have a flexible way of defining the artifacts that should be uploaded.

Is it possible to pass arguments/parameters into the script? We use a few different methods in our existing generic GitHub Actions to reliably detect the project name and version number: https://github.com/hms-networks/sc-java-maven-starter-project/blob/e8a808f0d251f1c594c3082916434b7218f2f951/.github/workflows/release-push-maven-repo.yml#L43.

The starter project also provides a consistent interface for the naming of release files. It can be expected that in a release, jvmrun will be present, as well as ${{ env.RELEASE_ARTIFACT_ID }}-${{ env.RELEASE_VERSION }}-full.jar. The only file that would be difficult to predict is the configuration file, which ideally should conform to *.json.

[it-hms]

Cumulocity specific regex were swapped for more generic ones. I tested thingworx and Osisoft connectors. Thingworx had an issue because it does not include config files in releases, but OsiSoft works.

[alexjhawk]

Cumulocity specific regex were swapped for more generic ones. I tested thingworx and Osisoft connectors. Thingworx had an issue because it does not include config files in releases, but OsiSoft works.

Is there any reason for the separate commit to make the action generic? Typically, if the commit that introduces the original code is in the same PR, the original commit should be modified to avoid extra commits.

[it-hms]

@oliver-walker-hms , could you please add you review