facelessuser / label-bot Goto Github PK

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

So, we are using the free Heroku server which is not always on. Maybe one day in the future we will change to a different one (maybe through funding via sponsorship), but currently, I don't plan to migrate away from the free solution. Occasionally, we can get app boot timeouts. We were getting them for a time, but they seem to have stopped occurring. I'm not sure if there is anything we can do to help speed up this process and become available faster, but something to look into.

I'm almost certain Heroku had just been having a period of performance issues.

Testing api

We probably need to get the code base unit tested. I'm not familiar with unit testing async/await code though, so I need to figure that out.

@gir-bot sync labels

Storing label definition in a config file on the repo itself is pretty great however there are many instances where like 70% of the labels are strictly the same across repos of a given org by design to enforce convention over common ones (Severity, Priority, Kind, etc..).

It would be great if there was a way to have a dedicated repo to host the master definition which could be complemented at the repo level for specific project need.

Clean up the code a bit for easier maintenance. The project came together pretty quick, and I was unfamiliar with projects of this type, so some cleanup needs to happen. Commands in comments (and issue bodies) should be split out into their own file and should be implemented a bit cleaner.

Add a way so we can say @bot lgtm in an issue, and it will clear any wip, triage, and/or review labels (depending on the issue type).

Optionally, you can say @bot lgtm, [key], where [key] is some user defined key, and appropriate labels will be set.

So, for an issue, I may say

@gir-bot lgtm, confirmed

And it may clear the triage label set the bug label and the confirmed label (as defined by the user).

Or if in a pull request, maybe:

@gir-bot lgtm, approved

And it would clear all the wip and review labels and set the label approved.

If we say:

@gir-bot lgtm

It would simply just remove the appropriate labels.

Once we get some stability, I want to transfer the repo back over to the main account: @facelessuser .

We can maintain it there.

@gir-bot add maintenance
@gir-bot lgtm

We are already waiting a second between each API call to keep GitHub from failing our calls, but we still get failures when we are bulk label adding. It only happens when we are setting up a repo for the first time, but we should maybe try and throttle a bit more so we don't have to run it twice. Once a repo is established, you are probably doing minor label changes.

@gir-bot add sync-labels, feature
@gir-bot lgtm

This will help identify which repo an issue occurs in.

@gir-bot add maintenance

The idea would be to provide an add and remove command that would read the config and find match the parameters to real labels. If desired, you could define aliases as well for labels that are awkward to enter. We'll probably limit the scanning for certain characters, and if the label has characters outside that range, you would need to define an alias.

This may be useful for simple triage. For instance:

@gir-bot add feature
@gir-bot lgtm

or

@gir-bot remove triage
@gir-bot  add bug, needs-confrimation

@gir-bot lgtm

Can we easily setup an app scoped just to our username via traditional GitHub app infrastructure?

Something to look into. What we are doing now works, but it requires a bit of manual setup. It would be nice if we could as a repository as easy as it is on the marketplace. But not have to support everyone as a public app.

@gir-bot add maintenance
@gir-bot lgtm

Documentation doesn't describe the reason @bot add label or @bot remove label additions.

@gir-bot add docs
@gir-bot lgtm

I think I finally figured out why label syncing fails, and it isn't because of rate limit abuse.

We were getting issue 422 which is essentially invalid field, and we would get for the attribute name. This would occur when we were specifically creating labels.

It finally occurred to me that we were paging repo labels while deleting or modifying labels. I realize now that this could cause some labels that would have appeared in the next page to not appear if labels were deleted before retrieving the next page. This is because labels on page X + 1 would now be on page X after the delete.

So why does this cause a 422? Because we missed indexing the label, and we think it needs to be created. So when we create it, it already exists, and so GitHub sends back a 422.

@gir-bot add bug, confirmed
@gir-bot lgtm

Commands that run automatically should not run on closed issues, but commands that are initiated by a manual command should still run on a closed issue.

For instance, if we are closing an issue and updated labels via commands in the comment, they should still execute even though the command will be closed by time label commands execute. Also, the manual command should be respected in general, particularly add add remove commands. These are simple commands that add and remove labels.

So maybe not all commands should execute when the issue is closed, but at least add and remove.

@gir-bot add T: feature
@gir-bot lgtm