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
Python	Travis/CircleCI	[x]	[x]	[]	[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 and Travis 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?

@alolita @Brandon-Kimberly

[codeboten]

@Brandon-Kimberly I took a brief look at github actions and it seemed not to support older versions of Python out of the box. Have you had a chance to look at whether we can support the full matrix of versions we're testing today?

One of the other benefits of using CircleCI was the ability to cache tox environments, is this something that's achievable with github actions? I'd love to see an example of this. See PR #828 for more details on the circle CI configuration.

[ffe4]

The versions from the test matrix should all be supported, although they might not be preinstalled on the runner. From the docs:

If a specific version of Python is not pre-installed in the tools cache, the setup-python action will download and set up the appropriate version from the python-versions repository.

The reference only lists the following as preinstalled on Ubuntu 20.04 LTS:

Python:
    Python 2.7.18
    Python 3.5.9
    Python 3.6.11
    Python 3.7.8
    Python 3.8.5
PyPy:
    PyPy 2.7.13 [PyPy 7.3.1 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
    PyPy 3.6.9 [PyPy 7.3.1 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]

But actions/python-versions seems to support the following:

$ curl -s https://raw.githubusercontent.com/actions/python-versions/main/versions-manifest.json | jq ".[].version"
"3.9.0-beta.5"
"3.9.0-beta.4"
"3.8.5"
"3.8.4"
"3.8.3"
"3.8.2"
"3.8.1"
"3.8.0"
"3.7.8"
"3.7.7"
"3.7.6"
"3.7.5"
"3.6.11"
"3.6.10"
"3.6.9"
"3.6.8"
"3.6.7"
"3.5.9"
"3.5.4"
"3.4.10"
"3.3.7"
"2.7.18"
"2.7.17"

Not sure about caching, but maybe we could use actions/cache for that.

[ffe4]

@codeboten I have not gotten it to work as expected yet (see #984), but caching should work, according to the migration guide.

[ffe4]

As an additional argument for switching to GitHub Actions:

After setting up my CircleCI on my fork I noticed that the checks on my pull requests did not complete. Apparently, if a user follows their own fork, CircleCI does not run these jobs on the main repository, even for pull requests. This results in the checks on the pull requests forever waiting for status to be reported.

See: Why aren't pull requests triggering jobs on my organization?