Add test coverage for per repository version uniqueness constraints
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 71
- Forks
- 91
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 22
Description
Author: @quba42 (quba42)
Redmine Issue: 7441, https://pulp.plan.io/issues/7441
Provide test coverage for: https://pulp.plan.io/issues/6429
I deferred the test coverage in the interest of getting this issue merged, but I still think test coverage would be useful (and at this point I have a fairly detailed idea of what would be needed):
Minimal test:
Create a repository
Upload https://fixtures.pulpproject.org/debian/pool/asgard/o/odin/odin_1.0_ppc64.deb to it.
Also upload https://fixtures.pulpproject.org/debian-complex-dists/pool/asgard/o/odin/odin_1.0_ppc64.deb to it.
Assert that the second repository version has only one package in it, and that the first package was removed from the version.
If we want to be fancy:
Add both packages to an empty repository in a single API call.
Assert that the relevant error is thrown.
Add both packages to the repository from the minimal test using a single API call.
Assert that the new version still only has one package in it.
Extra fancy:
Build a third colliding package in the fixtures.
Add all three to the repository from the minimal test in a single API call.
Assert that the relevant error is thrown.
Contributor guide
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
Start by locating the existing repository and repository-version tests and the API used to upload packages. Reproduce the minimal case with the two Debian fixture URLs, then verify that the second version retains one package and removes the first; if covering batch uploads, assert the stated error and resulting version contents.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, testing-qa
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100