open-telemetry / open-telemetry/opentelemetry-python-contrib

Improve our testing infrastructure

Open
#2,444 1 comment 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

build & infra
Dominant language
Python
Stars
1.1k
Forks
1.1k
Avg merge
4d 15h
Merged PRs (30d)
16

Description

I see several issues with our infrastructure:

  1. Lint is very slow. This mostly happens because we install every single package to create a virtual environment for linting.
  2. We are using tox.ini files instead of a pure python alternative.
  3. We use several bash scripts, instead of python scripts
  4. We use a script (eachdist.py) to run a few actions, which I think they can be moved into noxfile.py files
  5. We may be missing better tools to specify dependencies (like pipfile.lock files and such)
  6. We install several unnecessary dependencies every time we want to test our packages
  7. We may not be using the best tools or combination of tools for linting
  8. tox.ini is very long. It is easy to overlook testing errors in this huge file, it has happened before.

In more high-level, architectural terms, I feel like we have a huge monorepo where lots of different packages exist and our infrastructure is designed in the same way. For example, we have a single tox.ini file where everything needed to test any package is added, instead of having different tox.ini files, one for every package. The latter approach is better in my opinion since it keeps these files smaller and relevant only for the package they would be in. I have noticed several errors in our tox.ini file that have been there for a long time, since they are very hard to detect just because of how big and complex this file is.

The main reasons we have this monorepo approach is because we test every commit in the core repo against the test cases in these repo and we test the packages in the contrib repo against a particular commit of the core repo.

To be clear, I am not suggesting a change in this testing approach. The issues and possible solutions I mention in this issue are separate and independent from this approach.

My intention with this particular issue is just to find a solution for the points above. Even if we fix them all, we can continue with the cloning-the-core-repo testing approach.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the repository's tox.ini and eachdist.py, then inventory the bash scripts and package-specific testing configuration mentioned in the issue. Compare the current setup with the proposed alternatives and define a scoped, testable infrastructure plan; done should include measurable improvements without changing the monorepo testing approach.

Written by the indexing model from the issue text.

Assessment

Tech stack
bash, python
Domain
build-system, developer-experience, testing-qa
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.