Merge lp:~cjwatson/launchpad/github-use-issue-number into lp:launchpad
Status: | Merged | ||||
---|---|---|---|---|---|
Merged at revision: | 18927 | ||||
Proposed branch: | lp:~cjwatson/launchpad/github-use-issue-number | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
149 lines (+27/-23) 2 files modified
lib/lp/bugs/externalbugtracker/github.py (+4/-4) lib/lp/bugs/externalbugtracker/tests/test_github.py (+23/-19) |
||||
To merge this branch: | bzr merge lp:~cjwatson/launchpad/github-use-issue-number | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Tom Wardill (community) | Approve | ||
Launchpad code reviewers | Pending | ||
Review via email: mp+366083@code.launchpad.net |
Commit message
Expect the upstream bug ID in the "number" field of GitHub issue objects, not the "id" field.
Description of the change
I'm not sure how this ever worked. Possibly GitHub changed the semantics of the "id" field? It seems to now be a fairly arbitrary integer that we shouldn't be using for anything meaningful on our end, much like the distinction between "id" and "iid" in GitLab:
$ curl -s https:/
{"url":"https:/
{"url":"https:/
{"url":"https:/
https:/
Change lgtm. Wonder if the id field is now a global ID, rather than a repo specific id?