Skip to content

Make sure new private issues are assigned to the "unmoderated" milestone #3146

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

Closed
miketaylr opened this issue Jan 10, 2020 · 8 comments
Closed
Assignees

Comments

@miketaylr
Copy link
Member

miketaylr commented Jan 10, 2020

Depends on #3139 landing first.

https://github.com/webcompat/webcompat-tests-private/milestones already exists (as well as the corresponding milestone in the actual private repo).

We could do this in 2 ways:

  1. Just assign the right milestone in the initial issue payload in unmoderated_issue() in issues.py

  2. Write a webhook for new issues in the private repo to assign milestones for us.

We probably need to re-use the milestones checking machinery?

@miketaylr
Copy link
Member Author

@karlcow assuming #3147 is in the right direction, could you pick up this issue?

@karlcow
Copy link
Member

karlcow commented Jan 13, 2020

So I thought maybe we could try to use the fancy new GitHub Actions stuff.

And it didn't work. It failed with the message:

  • Workflows can't be executed on this repository. Please check your payment method or billing status.

So searching a bit the documentation.

GitHub Actions is available with GitHub Free, GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub One. GitHub Actions is not available for public or private repositories owned by accounts using legacy per-repository plans. For more information, see "GitHub's products."

Let's check the GitHub Free stuff.

There is also the Github Team Open Source

And I'm not sure about the billing. So I guess we need to fall back on our traditional webhook.

@karlcow
Copy link
Member

karlcow commented Jan 13, 2020

The second method doesn't have a dependency on #3139 . It is working on just monitoring events.

@karlcow karlcow self-assigned this Jan 13, 2020
@karlcow
Copy link
Member

karlcow commented Jan 13, 2020

Again here we have the issue of milestone number vs names.
https://github.com/webcompat/webcompat-tests-private/milestone/1

Here a non-tested possibility with webhook. Not very dry, not very clean. We could abstract the code so the previous covers the two cases BUT because the future of this code is bleak. I would rather not try to abstract if it's to do reconstructive surgery after.

diff --git a/webcompat/webhooks/__init__.py b/webcompat/webhooks/__init__.py
index d9f3fd99..8bcb3da3 100644
--- a/webcompat/webhooks/__init__.py
+++ b/webcompat/webhooks/__init__.py
@@ -53,3 +53,37 @@ def hooklistener():
         return ('pong', 200, {'Content-Type': 'text/plain'})
     # If nothing worked as expected, the default response is 403.
     return ('Not an interesting hook', 403, {'Content-Type': 'text/plain'})
+
+
+@app.route('/webhooks/quarantine', methods=['POST'])
+def quarantine_hook():
+    """Listen for the "issues" webhook event on private issues repo.
+
+    By default, we return a 403 HTTP response.
+    """
+    if not is_github_hook(request):
+        return ('Nothing to see here', 401, {'Content-Type': 'text/plain'})
+    payload = json.loads(request.data)
+    event_type = request.headers.get('X-GitHub-Event')
+
+    # Treating events related to issues
+    if event_type == 'issues':
+        issue = get_issue_info(payload)
+        # A new issue has been created.
+        # In the future we can add new type of actions.
+        if issue['action'] == 'opened':
+            # we are setting labels on each new open issues
+            response = assign_quarantine(payload)
+            if response.status_code == 200:
+                return ('gracias, amigo.', 200, {'Content-Type': 'text/plain'})
+            else:
+                log = app.logger
+                log.setLevel(logging.INFO)
+                msg = 'failed to set labels on issue {issue}'.format(
+                    issue=issue['number'])
+                log.info(msg)
+                return ('ooops', 400, {'Content-Type': 'text/plain'})
+    elif event_type == 'ping':
+        return ('pong', 200, {'Content-Type': 'text/plain'})
+    # If nothing worked as expected, the default response is 403.
+    return ('Not an interesting hook', 403, {'Content-Type': 'text/plain'})
diff --git a/webcompat/webhooks/helpers.py b/webcompat/webhooks/helpers.py
index e170f31b..247d1101 100644
--- a/webcompat/webhooks/helpers.py
+++ b/webcompat/webhooks/helpers.py
@@ -200,3 +200,40 @@ def new_opened_issue(payload):
         headers=headers,
         data=json.dumps(payload_request))
     return proxy_response
+
+
+def assign_quarantine(payload):
+    """Set the core actions on new anonymous opened issues.
+
+    When a new issue is opened, we set a couple of things.
+
+    - Milestone:
+    - Any "extra" labels, set from GET params
+
+    Then Send a GitHub PATCH to set labels and milestone for the issue.
+
+    PATCH /repos/:owner/:repo/issues/:number
+    {
+        "milestone": 1
+    }
+
+    https://github.com/webcompat/web-bugs-private/milestone/13
+    https://github.com/webcompat/webcompat-tests-private/milestone/1
+    """
+    issue_number = payload.get('issue')['number']
+    repo_uri = app.config['PRIVATE_REPO_URI']
+    # TODO: Remove or move to server side this hard coded logic
+    if 'web-bugs-private' in repo_uri:
+        milestone = 13
+    else:
+        milestone = 1
+    # Preparing the proxy request
+    headers = {'Authorization': 'token {0}'.format(app.config['OAUTH_TOKEN'])}
+    path = 'repos/{0}/{1}'.format(repo_uri, issue_number)
+    payload_request = {'milestone': milestone}
+    proxy_response = proxy_request(
+        'patch',
+        path,
+        headers=headers,
+        data=json.dumps(payload_request))
+    return proxy_response

@karlcow
Copy link
Member

karlcow commented Jan 13, 2020

btw I realized that for both new_opened_issue and this new assign_quarantine, we are not forced to use app.config['PRIVATE_REPO_URI'] or app.config['REPO_URI'], because the information is already there in the payload.

and removing the app.config for this case, would remove the out of band information that could be dangerous in case of misconfiguration.

@karlcow
Copy link
Member

karlcow commented Jan 13, 2020

The other case is much simpler, as basically it means that in build_formdata we need to send this

-    rv = {'title': summary, 'body': body}
+    rv = {'title': summary, 'body': body, 'milestone': 1}
    return rv

and here again we need to test which url we are reporting too to get the right milestone number (only for anonymous case).
We still need the webhook for authenticated users to set milestones, because I don't think they have the right to do it. But webcompat-bot has the right to do it. :)

karlcow added a commit to karlcow/webcompat.com that referenced this issue Jan 14, 2020
Right now, when testing, it's not really possible to override the anonymous reporting. This will make it possible depending on the scenario you need to test in your own .env
karlcow added a commit to karlcow/webcompat.com that referenced this issue Jan 14, 2020
… milestone

In the future, this should be probably in the `.env` or environment variable on the server.

Also it would be a possibility for us to clean up the code of initializing milestone. Aka instead of defining the milestone through http requests at the start of flask, we could just decide that the deploy script grab them if required and put them in env. Or even just write them down in server environment. Since we used them they never changed.
karlcow added a commit to karlcow/webcompat.com that referenced this issue Jan 14, 2020
…or moderation

Note that we could do the same kind of logic for needstriage on anonymous issue
@karlcow
Copy link
Member

karlcow commented Jan 14, 2020

to note one thing though.

If the milestone number is wrong, or basically anything else is wrong. GitHub is not doing a silent fail, they just drop everything and the public issue is posted, but the moderated one is dropped.

<Response [422]>

So not sure if we want to handle this case in the future.

@karlcow
Copy link
Member

karlcow commented Jan 14, 2020

This comment I Just made ties to #3148 too.

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

No branches or pull requests

2 participants