This repository has been archived by the owner on Feb 11, 2022. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 4
runs too quickly to ensure all commit-checks pass #77
Labels
Comments
an example of the list of statuses: Statuses "statuses": [
{
"url": "https://api.github.com/repos/travi/travi-api/statuses/63d79f4c120e838c3d632543c91bd2c12d74438e",
"id": 1076443100,
"state": "success",
"description": "Dependencies checked",
"target_url": "https://dependencyci.com/builds/167884",
"context": "dependency-ci",
"created_at": "2017-03-13T07:00:04Z",
"updated_at": "2017-03-13T07:00:04Z"
},
{
"url": "https://api.github.com/repos/travi/travi-api/statuses/63d79f4c120e838c3d632543c91bd2c12d74438e",
"id": 1076443762,
"state": "success",
"description": "No failing files.",
"target_url": "https://www.bithound.io/github/travi/travi-api/63d79f4c120e838c3d632543c91bd2c12d74438e/files?status=passing",
"context": "bitHound - Code",
"created_at": "2017-03-13T07:00:38Z",
"updated_at": "2017-03-13T07:00:38Z"
},
{
"url": "https://api.github.com/repos/travi/travi-api/statuses/63d79f4c120e838c3d632543c91bd2c12d74438e",
"id": 1076443763,
"state": "success",
"description": "No failing dependencies.",
"target_url": "https://www.bithound.io/github/travi/travi-api/63d79f4c120e838c3d632543c91bd2c12d74438e/dependencies/npm?status=passing",
"context": "bitHound - Dependencies",
"created_at": "2017-03-13T07:00:38Z",
"updated_at": "2017-03-13T07:00:38Z"
},
{
"url": "https://api.github.com/repos/travi/travi-api/statuses/63d79f4c120e838c3d632543c91bd2c12d74438e",
"id": 1076443804,
"state": "success",
"description": "Greenkeeper verified pull request",
"target_url": "https://greenkeeper.io/verify.html",
"context": "greenkeeper/verify",
"created_at": "2017-03-13T07:00:40Z",
"updated_at": "2017-03-13T07:00:40Z"
},
{
"url": "https://api.github.com/repos/travi/travi-api/statuses/63d79f4c120e838c3d632543c91bd2c12d74438e",
"id": 1076444800,
"state": "success",
"description": "No known vulnerabilities found",
"target_url": "https://nodesecurity.io/orgs/travi/projects/2f6e0dcc-a394-4789-95a9-226c1f8d7d27/428",
"context": "Node Security",
"created_at": "2017-03-13T07:01:34Z",
"updated_at": "2017-03-13T07:01:34Z"
},
{
"url": "https://api.github.com/repos/travi/travi-api/statuses/63d79f4c120e838c3d632543c91bd2c12d74438e",
"id": 1076444883,
"state": "success",
"description": "No new vulnerabilities",
"target_url": "https://snyk.io/test/github/travi/travi-api/63d79f4c120e838c3d632543c91bd2c12d74438e?fromStatus=true",
"context": "security/snyk",
"created_at": "2017-03-13T07:01:38Z",
"updated_at": "2017-03-13T07:01:38Z"
},
{
"url": "https://api.github.com/repos/travi/travi-api/statuses/63d79f4c120e838c3d632543c91bd2c12d74438e",
"id": 1076445473,
"state": "success",
"description": "The Travis CI build passed",
"target_url": "https://travis-ci.org/travi/travi-api/builds/210460129",
"context": "continuous-integration/travis-ci/push",
"created_at": "2017-03-13T07:02:10Z",
"updated_at": "2017-03-13T07:02:10Z"
},
{
"url": "https://api.github.com/repos/travi/travi-api/statuses/63d79f4c120e838c3d632543c91bd2c12d74438e",
"id": 1076446873,
"state": "success",
"description": "The Travis CI build passed",
"target_url": "https://travis-ci.org/travi/travi-api/builds/210460448",
"context": "continuous-integration/travis-ci/pr",
"created_at": "2017-03-13T07:03:30Z",
"updated_at": "2017-03-13T07:03:30Z"
},
{
"url": "https://api.github.com/repos/travi/travi-api/statuses/63d79f4c120e838c3d632543c91bd2c12d74438e",
"id": 1076446880,
"state": "success",
"description": "Coverage remained the same at 100.0%",
"target_url": "https://coveralls.io/builds/10558779",
"context": "coverage/coveralls",
"created_at": "2017-03-13T07:03:31Z",
"updated_at": "2017-03-13T07:03:31Z"
}
], |
travi
added a commit
that referenced
this issue
Mar 30, 2017
hoping that use of the status-event can replace the use of the pull_request-event, but this enables the choice for now. the intent is that one or the other should be used, not both. this is to prevent collisions between polling from the pull_request-event and the more intentional status-event processing. switching to the status-event eliminates polling, which allows acceptance to be triggered after what would have been beyond the polling timeout. hopefully this will also improve the behavior related to #77 because a successful status would need to be reported after the PR is opened. ideally this gives enough time for all checks to be registered for #21
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
from my observations, this appears to be a result of checks being registered after the PR being opened sometimes taking longer to be registered than the time it takes for greenkeeper-keeper to execute.
this manifests in a few different end results:
there does not appear to be a way to know which checks would register after a PR is opened until after they have the time to register themselves
The text was updated successfully, but these errors were encountered: