Infra/fairspc 23 GitHub actions ci

[tgreenwood]

NOTE: agreed with Frank that first we need to discuss all together the release strategy and tagging strategy before accepting the approach from the pull request. I will schedule a call on the beginning of January

1. Two new Github Actions CI workflows were introduced. One is for build services on pull request related events (all jobs for services are run in parallel). Another one is for pushes to 'dev' branch (flow described in the 'build_and_upload_on_push_to_dev.yaml' file)
2. TravisCI related files are still present: new tickets to be created to introduce workflows for documentation, releases, tags, etc.
3. Now versions (images' tags) are equal for all images per build and unique (date-time is appended)

PS: all commits will be shrinked into one with proper message on merge

[frankyhollywood]

although it is nice and specific, I wonder if we need the date timestamp, it will lead to many different package files. I would just create a 'latest' stamp, which is always the latest build. Introduce the timestamps at a point where we really need this.

Also I would like distinction between dev and release builds. Everything from the release branch should be ready to ship to production, this is not what I expect from a dev image. Let's discuss in the office today how to manage this.

[tgreenwood]

good points, let's discuss it in the office

I will play a bit with the latest tag in the meantime

[tgreenwood]

TBD: release strategy + tagging

[tgreenwood]

Agreed with @ewelinagr and @frankyhollywood :

• to hold only the latest version of snapshots (no timestamps needed)
• add the release flow triggered on a merge to the release branch: (RELEASE-[version])
• commit a minor version increment change once release has been created
• create ticket for helm charts