Repository navigation
feat: Link maintainers to package - #1406
Conversation
fricklerhandwerk
left a comment
fricklerhandwerk
left a comment
There was a problem hiding this comment.
Just some style nits, great work!
| # NOTE(@fricklerhandwerk): Extracted query into procedure to instrument testing against race conditions. | ||
| attrpath_to_pkg = package_from_attrs(drvs) | ||
|
|
||
| on_tracking_branch = set( |
There was a problem hiding this comment.
By construction when update_packages is set all drvs are from the tracking branch, so we may skip this test and the filter later. It's not wrong to be defensive here, but also it's probably quite a performance hit?
There was a problem hiding this comment.
We're running cluster backfilling on each startup, so this can be folded into there. The only thing we may consider is the one-time backfill of just the maintainers, and that could maybe happen in a migration? That may make the backfill command slightly simpler, but may be not even. If the only difference is that the first run with the maintainer additions is longer, that's fine.
| cluster_packages(NixDerivation.objects.filter(pk=drv.pk)) | ||
|
|
||
| package = PackageDerivation.objects.get(derivation=drv).package | ||
| assert list(package.maintainers.all()) == [maintainer] |
There was a problem hiding this comment.
It would be more obvious if we take drv...maintainer, because otherwise you have to Just Know that the fixture uses maintainer for derivation (and that may change in the future).
| release_branch=make_branch(name="release-26.05"), | ||
| ) | ||
| ) | ||
| rolling = make_evaluation(channel=make_channel()) |
There was a problem hiding this comment.
Can we maybe make it more explicit that this eval is on the tracking branch? IIRC there's a branch parameter.
8945b4a to
3e6e417
Compare
3e6e417 to
96b58ed
Compare
Linking Maintainers to Package, for easy fetching of package maintainers through package without having to go through the Deriviations