Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect package better for PRs that don't touch default.nix #383

Open
lilyball opened this issue Aug 8, 2019 · 1 comment
Open

Detect package better for PRs that don't touch default.nix #383

lilyball opened this issue Aug 8, 2019 · 1 comment

Comments

@lilyball
Copy link
Member

lilyball commented Aug 8, 2019

When I submit a PR for a bundlerApp package where all I did was modify the Gemfile.lock and gemset.nix files, ofborg doesn't detect the package and therefore doesn't label my PR correctly (e.g. it's missing 8.has: package (update) and 11.by: package-maintainer).

Example PR: NixOS/nixpkgs#66251

I'm not actually sure what logic ofborg uses to detect the packages modified by the PR, so I don't know what the best approach for teaching it about this scenario. One simple possibility would be if the PR title or any commit in the PR follows the format "attrname: …" then check that attribute and see if anything in it was modified by the PR. That simple check would handle the above PR, because the cocoapods-beta attribute is a derivation that references both Gemfile.lock and gemset.nix (and in fact its version attribute is also changed since that comes from gemset.nix).

@FRidh
Copy link
Member

FRidh commented Oct 15, 2019

If ofborg can also use the commit titles, then I don't think we need to complicate the part that detects based on files. In that case it is related to #318.

E.g., foobar: 50 -> 60 is simply an upgrade for which we have a label, and foobar: init at 50 is a new package. Maybe we only need to check whether it is in the nixos/ folder or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants