MetaMask / MetaMask/metamask-module-template
Compatibility tests should not block PRs
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 31
- Forks
- 18
- Avg merge
- 11h 39m
- Merged PRs (30d)
- 1
Description
The "compatibility tests" are very helpful for discovering unexpected breaking changes in our dependencies. However, they rarely are caused by changes in individual PRs, but rather indicate breakages in dependencies. As such, they aren't useful as a PR status check.
Ideally PR status checks would be solely focused on catching regressions caused by the PR itself, to avoid blocking unrelated work and to avoid sending contributors on wild goose chases.
We could accomplish this by only running the compatibility tests on `main`. Moving them to a separate workflow would also make the results easier to understand for the team (e.g. so we don't think that our main regression suite is broken).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the workflow that currently runs the compatibility tests and review how it contributes to pull-request status checks. Done means compatibility tests run separately on main while pull-request checks remain focused on regressions caused by the proposed changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- ci-cd, testing-qa
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100