mozilla-releng / mozilla-releng/tooltool

tooltool client location, duplication and usage

Open
#7 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
2
Forks
14
Avg merge
1d 6h
Merged PRs (30d)
2

Description

Hey, the doc says

If you want to use the client, just copy out tooltool.py -- it has no dependencies.

I think it's a problem.

Having people copy that script here and there has two major disadvantages:

  • it leads to some issues of having deprecated tooltool.py instances in many places.
  • it makes it hard to deploy a new improved version
  • we don't know if the version we use is the right one

For example the version in this repo says version == '1' but the one in mozharness
has the same version but is a different module.

We bumped into the issue because we started to work on https://phabricator.services.mozilla.com/D54090 to add a small retry mechanism to try
to reduce intermittents on Raptor, and decided to use mozbuild's tooltool version as
the source of truth, but it turns out this repo is the one :)

there's also https://github.com/mozilla/build-relengapi ?

I would like to make this proposal:

  • ask people not to copy around tooltool.py
  • remove all tooltool.py instances in mozilla-central
  • release on pypi and our internal pypi a tooltool client with no dep that can be used in all py versions
  • make that package a commodity everywhere in our CI and tests environements

Contributor guide

No contributing guide indexed for this repository

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 comparing this repository's tooltool.py with mozharness/client/tooltool.py and the mozbuild version mentioned in the issue. Trace where copied tooltool.py instances are used in mozilla-central and CI, then assess the PyPI and internal PyPI packaging requirements. Done means there is an agreed single distributable client and a migration plan for existing copies.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli, devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.