Add CICD for docker image deployment

[cjenkscybercom]

(WIP - DO NOT MERGE - testing by running on GitHub)

• cicd: setup scripts for making project info available to cicd for e.g. docker image tags

[cjenkscybercom]

@georgweiss I've put together some bash scripts you can run locally if you wish, otherwise just check the last lines of the "Build and push" step in the latest run: https://github.com/Olog/phoebus-olog/actions/runs/4135819135

#19 exporting to image
#19 exporting layers
#19 exporting layers 1.9s done
#19 writing image sha256:2a7c0bbd61eb67160a84b893dbc77b914e43cc26b8a529884bd41255cab23145 done
#19 naming to ghcr.io/olog/org-phoebus-service-olog:latest done
#19 naming to ghcr.io/olog/org-phoebus-service-olog:4.7.2 done
#19 naming to ghcr.io/olog/org-phoebus-service-olog:4.7.2-20230209153117 done
#19 DONE 1.9s

I'm creating an image with three tags:

• latest (as it is the latest image, by convention)
• the groupId-artifact-version
• the groupId-artifact-version with a timestamp

This ensures that one can e.g. pull by version but also that we have a specific one available by timestamp as well (if e.g. there was more than one release for whatever reason).

Granted, folks using the docker images should refer to them by SHA, e.g.

Best Practice (always refers to a unique image):

FROM ghcr.io/olog/org-phoebus-service-olog@sha256:2a7c0bbd61eb67160a84b893dbc77b914e43cc26b8a529884bd41255cab23145

Not-So-Great Practice (a given image can have its tags overwritten):

FROM ghcr.io/olog/org-phoebus-service-olog:4.7.2

Anyway, let me know if you have any questions. Once all is well, I'll make another commit to enable pushing to the GitHub registry (don't merge until I do). At the moment is only building the image and tagging it, not pushing it anywhere.

[cjenkscybercom]

Edit: upgraded y'all to v3 since v2 uses the deprecated way of passing around env vars in github actions: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

I'd go with v4 but was released literally last week so...That can wait.

[cjenkscybercom]

I'm sorry, I fail to understand how to review this. What are the criteria for verifying that this PR is OK? I guess this PR is to ensure that a usable docker image can be built, right? If so, how do I verify the image?

The dockerfile definition already exists and works, the purpose of this PR is to make that image available remotely via GitHub's container registry.

The way you can verify this is ultimately to look at the run logs above.

• Does the docker image get built successfully?
• Do the tags that are being associated to it make sense? (I used group id, artifact id, version, and a timestamp to generate three tags for each image that will be built, e.g. current, group-artifact-version, and group-artifact-version-timestamp)
• Do the tags follow tagging guidelines (no uppercase characters, no whitespace)

You can also run the scripts locally, though all these do is setup the environment required to make the tags (this is the involved part, as we're extracting info from maven) and has more use in debugging locally than anything else.

Does that help clarify things for you?

[cjenkscybercom]

Also, to be clear, there is a last step -- which is to set publish=true so we can e.g. verify the image is actually published. But I didn't want to publish anything until the tag names made sense to you @georgweiss

[georgweiss]

Sorry, still quite confused.

Running the script set-github-env.sh produced:

usage: touch [-A [-][[hh]mm]SS] [-achm] [-r file] [-t [[CC]YY]MMDDhhmm[.SS]] [-d YYYY-MM-DDThh:mm:SS[.frac][tz]] file ... set-github-env.sh: line 12: PROJECT_INFO.txt: No such file or directory

[cjenkscybercom]

Sorry, still quite confused.

Running the script set-github-env.sh produced:

usage: touch [-A [-][[hh]mm]SS] [-achm] [-r file] [-t [[CC]YY]MMDDhhmm[.SS]] [-d YYYY-MM-DDThh:mm:SS[.frac][tz]] file ... set-github-env.sh: line 12: PROJECT_INFO.txt: No such file or directory

Did you run the local setup first? (from the readme changes -- make sure to source the file, not execute it; this sets environment vars etc that would be in GitHub runner environments)

# Running Locally

source ./setup-locally.sh
./write-project-info.sh
./set-github-env.sh

[cjenkscybercom]

As clarified in the discussion:

• leave snapshot in the image tag because merge to master is not a release. the release is manual currently, and that can be discussed separately
• clarify the purpose of the scripts a bit better, e.g. how to use them to debug a test run and what the image tags should look like
• move the README info to the parent folder; if run locally, maven uses a default kind of POM that can give misleading results
• add the generated files to the gitignore, so they aren't accidentally committed

Unrelated, I'll also fix some issues I noticed:

• the original docker build has been running on every push (to any branch) as well as pull request. This script should:
  • build (but not push) on pull requests
  • only build-and-push on push to master

[cjenkscybercom]

Related: as discussed we are fine with having duplicate runs of the Java binary build/test due to triggering the GH action on both push and pull_request, as this is how it is done on Phoebus.

[cjenkscybercom]

As discussed, since the new workflow wont' show up until merged to master (and currently wont' actually push the image) we'll just go ahead and approve the PR and then create a separate one to turn it on (and fix any issues if they show up) rather than do something fancy like creating an empty workflow on master so we can trigger it here in the PR.