ci: migrating to GitHub actions

[JBAhire]

Description

Migrating to GitHub actions from CircleCI as per hypertrace/hypertrace#144

Testing

changes are updates as per discussions and workflow here: hypertrace/query-service#47

Checklist:

• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• Any dependent changes have been merged and published in downstream modules

Documentation

• https://docs.github.com/en/free-pro-team@latest/actions

[aaron-steinfeld]

Remove .DS_Store (and please update the .gitignore file) - this applies across many of these PRs

[aaron-steinfeld]

This can move into the test workflow, no secrets are used requiring p_r_target

[JBAhire]

yes but there are no tests here so kept in the same file as we are keeping it in build and validate workflow at other places.

[aaron-steinfeld]

Given that the workflows are divided by triggers though,

• Would it make sense to merge the docker workflow into the other
• In other places, I would move it too - p_r_target is a last resort for a couple different reasons (less secure, difficult to change since not workflow changes aren't testable without merging)

[JBAhire]

• we shouldn't merge docker workflow into other as I will be moving that to pull_request separately.
• I can create separate wokflow for that now and then I will merge that with e2e workflow when I will handle that.
• or we can keep it as it is now and then handle with e2e solution.

[aaron-steinfeld]

Unless you feel strongly, my preference would be to create the separate p_r based workflow now since that's a different issue than the e2e test one. If we want to leave the e2e as its own workflow pending the resolution around tags, that's fine.

Another thought about the e2e solution though - it's currently not doing a docker login before building the image, unlike in the build job. So...

• Accept that it might get rate limited, unless we know of some reason why it wouldn't. In this case, we might as well remove the login from build and put that in a p_r triggered workflow too.
• Keep it in a p_r_target workflow (and maybe just replace the build job since it appears to be a superset of it)
• Migrate our base images to GHCR and not worry about rate limiting. This seems ideal, but is a separate piece of work most likely (but if its our go forward strategy, accepting the temporary rate limiting may be acceptable)

[JBAhire]

Okay. will convert build workflow to pull_request and remove creds as this repo won't be getting lot of PRs anyways. Let's plan the base image migration to GHCR once this Github actions migration is completed

[JBAhire]

made similar change to all data service repos.