Proposal: Use GitHub Actions for CI/CD

[Brandon-Kimberly]

This issue is in reference to issue 398 posted on the community repository. In this issue, we are proposing that all OpenTelemetry repositories consider using GitHub Actions as their CI provider in order to maintain consistency across the various language repositories.

The overall proposal was discussed in the OpenTelemetry maintainers SIG meeting. @trask has been assigned as the mentor for the project.

Repository	CI Provider	Automated Build and Test	Code Coverage	Automated Performance Testing	Automated Deployment	Automated Docs Deployment
Go	CircleCI	[x]	[x]	[]	[]	[]

The justification and benefits are enumerated in the issue on the community repository and are pasted here as well for convenience:

Proposal

We propose that all languages consider using the same CI provider. This would create a more consistent development process and make it easier for developers to contribute to multiple language libraries.

We suggest that provider be GitHub Actions. Here’s why:

Ease-of-Use

CircleCI will automatically run when pull requests and commits are issued against the repository. But if a contributor forks the repository, unless they set up an account with the CI provider and link it to their forked repository, CI will not be activated and tests will not be run automatically.
In contrast, GitHub Actions works out of the box on a forked repository and can be easily configured to run a test workflow each time a commit is issued. This would help individual contributors test their code and ensure code quality before submitting a pull request against the repository.

Transparency

Current CI providers such as CircleCI allow anyone to view the console output when building and running tests but the test results can not be seen anywhere on the GitHub repository. To view this testing output: You need go to a different website, navigate a different user interface, and then sift through thousands of lines of console output. This is not a seamless developer experience.
In contrast, using GitHub Actions would provide all testing output directly on the repository’s GitHub page, which would help contributors to find, read, and use the test output to maintain code quality.

Control

GitHub Actions’ integration with other GitHub features means you can have finer control over the CI pipeline. For example, certain workflows can be set to only run on a new release. Workflows can even be used to close stale issues and pull requests.

Recommendation

We recommend that we consider using one consistent CI provider, GitHub Actions, which provides an integrated and seamless developer experience for all contributors.

Example

Please see this example that the C++ repository has adopted for the above reasons.

Next Steps

This issue shall serve as a place for discussion about this proposal.

Could a maintainer please assign this issue to us if approved?

cc: @Brandon-Kimberly @alolita

[lizthegrey]

I'm not sure the stated concern is true: when I fork the repo and then open a PR (e.g. a draft PR) against otel-go, it builds as expected.

[dabangarang]

I'd be willing to work on this! Could I please be assigned along with my mentor @alolita ? Thanks!

[MrAlias]

@danielbang907 let's make sure @lizthegrey is on board before you start work so nothing is thrown away. Also, it sounds like (after I read the description again) @Brandon-Kimberly and @alolita were looking to work on this. Do you have an affiliation with them?

@lizthegrey: are you opposed to this or just pointing things out?

We discussed this at last week's SIG meeting and there was ambivalence about this. It was pointed out that the CircleCI setup was working and it didn't seem critical to switch. However, if there was a strong desire and someone who wanted to work on this, then there was no real opposition from the attendees in pursuing this.

[lizthegrey]

I feel ambivalent, given that the Collector has a strong reason to stay on CircleCI, I think we should stay as well.

[MrAlias]

@Aneurysm9 pointed out that this might alleviate resource starvation issues that we are seeing on CircleCI. @Brandon-Kimberly do you know what resource quantities are available with GitHub actions?

[MrAlias]

At this point I'm interested to see if there is a behavior difference in resource starvation with GitHub actions.

@danielbang907 (cc @alolita): looking forward to your PR. (Sorry about the confusing comment I left above, on second read the affiliation was quite clear).

[MrAlias]

@danielbang907 on the implementation, can we leave the CircleCI stuff as is for now so we can evaluate side-by-side for a bit?

[alolita]

Hi @MrAlias - we're working on this proposal to migrate to GH Actions from CircleCI. Please assign @AzfaarQureshi @shovnik @alolita to this issue.

cc: @tedsuo @andrewhsu

[AzfaarQureshi]

Now that I'm migrating the CI jobs anyways, what do the maintainers think about me adding a CD workflow? (@MrAlias @Aneurysm9 @any_other_interested_party)

I was thinking about adding two workflows: publish and nightly.

For publish I would just copy the steps from RELEASING.md, so the new releasing workflow could be something like:

1. maintainers would add a release tag, open up a PR
2. PR gets merged into master
3. The publish job gets triggered when it sees the release tag on master

Once publish is made, nightly would be trivial as it's just calling pubilsh but with a :nightly release tag. I think a nightly release would be useful because we could check daily if our builds are passing and it would also provide easier access to an up-to-date build for those closely working with OpenTelemetry.

[MrAlias]

I was thinking about adding two workflows: publish and nightly.

For publish I would just copy the steps from RELEASING.md, so the new releasing workflow could be something like:

1. maintainers would add a release tag, open up a PR
2. PR gets merged into master
3. The publish job gets triggered when it sees the release tag on master

Once publish is made, nightly would be trivial as it's just calling pubilsh but with a :nightly release tag. I think a nightly release would be useful because we could check daily if our builds are passing and it would also provide easier access to an up-to-date build for those closely working with OpenTelemetry.

I think this sounds like a good idea, though I would probably tackle it as a follow-on issue to not have this issue dramatically increase in size. The details about how things are versioned and the human checks we put in place are going to be very important. Mistakes to releases are not retractable once they hit the Go package mirrors.

[AzfaarQureshi]

@MrAlias @Aneurysm9 The PRs for migrating the existing CircleCI jobs are ready for review on core (#1382) and contrib(#476) 😄

I'll open up an issue for the CD jobs right after this

[AzfaarQureshi]

Filed that CD issue we were talking about here :) #1385

Would love to hear your thoughts/comments!

[MadVikingGod]

We have migrated the CI workflow to GH Actions, and have created a CD workflow in the same. Is there any action left on this ticket?

[MrAlias]

We have migrated the CI workflow to GH Actions, and have created a CD workflow in the same. Is there any action left on this ticket?

Agreed, I think this is done. Please reopen if not.