Repository navigation
labels: prevent new labels being created - #80
Conversation
These changes prevents the bot from creating new labels which doesn't already exist in the node repo. Closes nodejs#58
7209a38 to
d4b3edc
Compare
|
@nodejs/github-bot anyone willing to approve and share the blame on this one? |
|
Didn't we originally do this? I have a recollection of it. |
|
Earlier we fetched which labels were already added to a PR before adding This is not related, as this ensure new repo labels aren't created in the On Tuesday, 27 September 2016, Jeremiah Senkpiel notifications@github.com
|
|
Oh right. Do we need to do this for every check, or can we do it like.. once every hour? |
|
Good idea, once an hour should be sufficient. I'll fix On Tuesday, 27 September 2016, Jeremiah Senkpiel notifications@github.com
|
|
Long overdue, but I just pushed cache w/1 hour expiry for the existing repo labels as suggested. PTAL |
|
@nodejs/github-bot this has stalled a bit, but I'll merge this within a day or two if there's no more comments or objections |
After PR nodejs#80 got merged, no labels were added to new PRs. That regression probably came from the fact that the existing repository labels was fetched and compared to the label names our labelling algorithm thought we should add. The problem is that we compared the whole label meta object (from api.github.com) against a label name (string). Example of the two different types of objects: ``` // complete label object { "url": "https://api.github.com/repos/nodejs/node/labels/buffer", "name": "buffer", "color": "f7c6c7" } // label name "buffer" ``` Comparing two such objects will obviuosly never match. These changes extracts the existing repo label *names* for comparison, and adds more logging for future debugging purposes.
After PR #80 got merged, no labels were added to new PRs. That regression probably came from the fact that the existing repository labels was fetched and compared to the label names our labelling algorithm thought we should add. The problem is that we compared the whole label meta object (from api.github.com) against a label name (string). Example of the two different types of objects: ``` // complete label object { "url": "https://api.github.com/repos/nodejs/node/labels/buffer", "name": "buffer", "color": "f7c6c7" } // label name "buffer" ``` Comparing two such objects will obviuosly never match. These changes extracts the existing repo label *names* for comparison, and adds more logging for future debugging purposes.
2 participants
As @jasnell reported in #58, the bot (unexpectedly) creates new repo labels once in a while. These changes prevents that from happening, by checking which labels already exists in the repo, before adding labels to PRs.
Closes #58