{"action":"created","issue":{"url":"https://api.github.com/repos/taskcluster/taskcluster-rfcs/issues/130","repository_url":"https://api.github.com/repos/taskcluster/taskcluster-rfcs","labels_url":"https://api.github.com/repos/taskcluster/taskcluster-rfcs/issues/130/labels{/name}","comments_url":"https://api.github.com/repos/taskcluster/taskcluster-rfcs/issues/130/comments","events_url":"https://api.github.com/repos/taskcluster/taskcluster-rfcs/issues/130/events","html_url":"https://github.com/taskcluster/taskcluster-rfcs/issues/130","id":369319855,"node_id":"MDU6SXNzdWUzNjkzMTk4NTU=","number":130,"title":"Switching to checks API in tc-gh","user":{"login":"owlishDeveloper","id":18102552,"node_id":"MDQ6VXNlcjE4MTAyNTUy","avatar_url":"https://avatars1.githubusercontent.com/u/18102552?v=4","gravatar_id":"","url":"https://api.github.com/users/owlishDeveloper","html_url":"https://github.com/owlishDeveloper","followers_url":"https://api.github.com/users/owlishDeveloper/followers","following_url":"https://api.github.com/users/owlishDeveloper/following{/other_user}","gists_url":"https://api.github.com/users/owlishDeveloper/gists{/gist_id}","starred_url":"https://api.github.com/users/owlishDeveloper/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/owlishDeveloper/subscriptions","organizations_url":"https://api.github.com/users/owlishDeveloper/orgs","repos_url":"https://api.github.com/users/owlishDeveloper/repos","events_url":"https://api.github.com/users/owlishDeveloper/events{/privacy}","received_events_url":"https://api.github.com/users/owlishDeveloper/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-10-11T21:54:19Z","updated_at":"2018-10-12T22:47:57Z","closed_at":null,"author_association":"MEMBER","body":"Relevant literature: https://developer.github.com/v3/checks/\r\nI started implementing here https://github.com/taskcluster/taskcluster-github/pull/278\r\n\r\nThe above needs more work in these areas:\r\n- Decision tasks\r\n- Maintaining compatibility with the current status API so that the third party tools that use statuses would still work.\r\n\r\nDecision tasks part itself has two parts:\r\n- **Displaying the tasks** started by the decision task as checks (which is easy: `jobHandler` will create the check for the decision task, and then, as we will be getting messages from the Queue, I will check if the task that came is in our DB - if yes, I'll update the checkrun, if not - I'll create one and put it into our DB).\r\n- **Retriggering tasks**. So Github has \"Retrigger All\" and \"Retrigger Check\" buttons in the UI which are there whether you want them or not ✨ Pressing them will generate a webhook for us to catch. The former button is always there, and the latter button appears once the task is completed. For the above PR, I did not intend to make that button functional - the above PR is the first part of the work, and it's for displaying statuses only. For the second part of the work tho, I'll need to figure out a way of retriggering the tasks. \r\n\r\n_I propose:_ the \"Retrigger All\" button restarts, well, all using deprecated✨ `rerun` API of the queue. the \"Retrigger Check\" button will create a new taskcluster task in the same taskgroup. The checkrun status will be tied to this new task. I would like to display the inspector links for both of the tasks in that check.\r\n\r\n- **Maintaining compatibility** would probably make sense for the above PR. I am not sure what it means yet tho. There can be a lot of third party tools out there, I would guess... I would need more information on how they work. What I can say so far - it seems to me if you create check suites and check runs, you would not be able to get the statuses via `repos.getStatuses` (I'll test this some more, of course). Also, if the user doesn't give our integration the permission to read and write checks... I'm not sure what happens - apparently they are left stateles?? I don't call `repos.status.create`. \r\n\r\nSo, as far as I can tell right now, the only way to maintain compatibility would be to......create statuses alongside checks?? Or we can give people opportunity to decide if they want checks or statuses - in `.taskcluster.yml`?"},"comment":{"url":"https://api.github.com/repos/taskcluster/taskcluster-rfcs/issues/comments/429482844","html_url":"https://github.com/taskcluster/taskcluster-rfcs/issues/130#issuecomment-429482844","issue_url":"https://api.github.com/repos/taskcluster/taskcluster-rfcs/issues/130","id":429482844,"node_id":"MDEyOklzc3VlQ29tbWVudDQyOTQ4Mjg0NA==","user":{"login":"imbstack","id":127521,"node_id":"MDQ6VXNlcjEyNzUyMQ==","avatar_url":"https://avatars2.githubusercontent.com/u/127521?v=4","gravatar_id":"","url":"https://api.github.com/users/imbstack","html_url":"https://github.com/imbstack","followers_url":"https://api.github.com/users/imbstack/followers","following_url":"https://api.github.com/users/imbstack/following{/other_user}","gists_url":"https://api.github.com/users/imbstack/gists{/gist_id}","starred_url":"https://api.github.com/users/imbstack/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/imbstack/subscriptions","organizations_url":"https://api.github.com/users/imbstack/orgs","repos_url":"https://api.github.com/users/imbstack/repos","events_url":"https://api.github.com/users/imbstack/events{/privacy}","received_events_url":"https://api.github.com/users/imbstack/received_events","type":"User","site_admin":false},"created_at":"2018-10-12T22:47:57Z","updated_at":"2018-10-12T22:47:57Z","author_association":"MEMBER","body":"Let's do some more science to figure out how checks and statuses interact. I don't think it would be bad to create both, just something we should know if we need to do or not.\r\n\r\nAs for actions, I think we should think of a nice way to have automatic \"taskcluster actions\" like we generate for decision tasks in gecko for fallback of repos that don't have it here?"}}
{"actor":{"display_login":"imbstack"}}