Migrate from Travis to GitHub actions

[yurishkuro]

We hit the limit of "credits" that Travis provides. Even though the OSS credits are supposed to renew on Nov-23, it's a sign that we need to move away from Travis.

Checklist for migration to GH Actions:

• Unit Test + Coverage
• Protogen Test
• All-In-One
• Crossdock
• Crossdock OpenTelemetry
• Docker Build + Deploy Github action for jaeger packages and docker image #2740
• ES Integration Tests
• ES OpenTelemetry Integration Tests
• Kafka Integration Tests
• Cassandra Integration Tests
• Memory + Badger Integration Tests
• HotRod Application Build
• Update build badges in README (may need to add an expander section for all workflows, currently only Unit Test and FOSSA badges are shown)
• Find a way to cancel running workflows on a branch for stale commits. Travis had this as a configuration option, but GH Actions seem to require a special action in each workflow. Without this we'll be running a lot of redundant workflows.

We also need similar changes in the other repositories:

Required before the next Jaeger release:

• documentation Migrate release process to GitHub actions documentation#461
• jaeged-ui Migrate CI to GitHub Actions jaeger-ui#668

Can be done independently:

• Split into [meta] Migrate from Travis to GitHub actions #2691 (all other repos)

Screenshots from Travis

cc @jaegertracing/jaeger-maintainers @Ashmita152

[Ashmita152]

Sure I can pick this work but I am new to GitHub Actions, so it will take some time to get it working. Maybe we can have parallel builds for Travis and GitHub Actions for sometime and once we are satisfied, we can shutdown travis builds.

[yurishkuro]

We do continue using Travis builds, but for some reason they ran out of credits which are not refreshing.

The approach here is to take steps in the Travis matrix one at a time and convert each to GH actions. GH actions are, in the end, just like shell scrips, similar to .travis.yaml. This is a good example: https://github.com/open-telemetry/opentelemetry-specification/blob/master/.github/workflows/checks.yaml

[Ashmita152]

As part of this issue, we need to migrate following jobs from Travis to Github Actions.

Update: the check list is moved to issue description.

[yurishkuro]

We need to decide on the naming pattern for jobs. GitHub is annoyingly inconsistent, showing workflow/job in the Checks, but only job in the settings:

E.g. wth is build? Turns out it's FOSSA (I am going to rename it as I did in the Go client repo).

[yurishkuro]

Found another annoyance with GH naming - when looking at Checks tab, it only shows workflow names. So we have identically named rows:

I suggest the following naming:

• CI Cassandra / ci_cassandra
• CI Elasticsearch / ci_elasticsearch
• CI Elasticsearch OTEL / ci_elasticsearch_otel
• etc.

@Ashmita152 @jpkrohling ^

[Ashmita152]

Do you think we should use https://github.com/actions/cache for caching go modules. I feel it will improve the build times.

[yurishkuro]

Do you think we should use https://github.com/actions/cache for caching go modules. I feel it will improve the build times.

We'd need to see the data on how much it speeds up the build. I have a feeling that this is not going to be a significant portion of the overall time, but if it saves 2min our of 12min then it could be worth it.

[Ashmita152]

One more question: I noticed that ES OpenTelemetry Integration Tests runs the same script as ES Integration Tests in Travis CI. Wondering if we need to do that in Github Actions too or we can safely skip that.

[yurishkuro]

It is the same script, but the script checks for if [ "$ES_OTEL_INTEGRATION_TEST" == true ]; then

[Ashmita152]

Ah I see, thank you for bringing it to my notice.

[yurishkuro]

you may want to change that script to take an explicit parameter (default vs. otel) instead of silent dependency on env var.

[Ashmita152]

Agree. Sure I will update the script. I feel we have too much redundant shell scripts with actions based on env variables which can easily be missed if undefined. In long term, I think we might want to discuss how we want to go ahead.

[yurishkuro]

It's probably just laziness. Ideally script behavior should be defined by the arguments, not by env vars, at least not by optional vars (required vars that fail the script if not defined are a compromise). Writing arg parsing with getops is not more complicated though, so perhaps worth it.

[jpkrohling]

Do you think we should use https://github.com/actions/cache for caching go modules. I feel it will improve the build times.

This shouldn't be needed. GitHub sets a GOPROXY, which gets the modules from a "local" resource. I did enable caching for the Jaeger Operator but that didn't have a noticeable effect.

[yurishkuro]

Relevant blog post https://aws.amazon.com/blogs/opensource/migrating-cortex-ci-cd-workflows-to-github-actions/

[yurishkuro]

@Ashmita152 to confirm, is the current status correctly reflected in the checkboxes in issue description? I.e. just two more workflows remaining.

[Ashmita152]

Hi @yurishkuro

Sorry for the delay on my side. Yes those are the only two workflows remaining. I will pick them this week.