github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2026-01-05 15:37:24 +00:00
Code Issues Projects Releases Wiki Activity

Remove Shippable

Browse Source
This commit is contained in:
Wojciech Tyczynski
2016-04-05 01:31:01 +02:00
parent 4f329516ae
commit 57b76eff45
3 changed files with 5 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/devel/automation.md
View File

@@ -67,7 +67,7 @@ The status of the submit-queue is [online.](http://submit-queue.k8s.io/)
A PR is considered "ready for merging" if it matches the following:
* it has the `lgtm` label, and that `lgtm` is newer than the latest commit
* it has passed the cla pre-submit and has the `cla:yes` label
* it has passed the travis and shippable pre-submit tests
* it has passed the travis pre-submit tests
* one (or all) of
* its author is in kubernetes/contrib/submit-queue/whitelist.txt
* its author is in contributors.txt via the github API.
@@ -103,7 +103,7 @@ Currently this runs:
* needs-rebase - Adds `needs-rebase` to PRs that aren't currently mergeable, and removes it from those that are.
* size - Adds `size/xs` - `size/xxl` labels to PRs
* ok-to-test - Adds the `ok-to-test` message to PRs that have an `lgtm` but the e2e-builder would otherwise not test due to whitelist
* ping-ci - Attempts to ping the ci systems (Travis/Shippable) if they are missing from a PR.
* ping-ci - Attempts to ping the ci systems (Travis) if they are missing from a PR.
* lgtm-after-commit - Removes the `lgtm` label from PRs where there are commits that are newer than the `lgtm` label
In the works:
@@ -130,7 +130,7 @@ PR builder to re-run the tests. To do this, reply to the PR with a message that
Right now you have to ask a contributor (this may be you!) to re-run the test with "@k8s-bot test this"
### How can I kick Shippable to re-test on a failure?
### How can I kick Travis to re-test on a failure?
Right now the easiest way is to close and then immediately re-open the PR.

4
docs/devel/on-call-build-cop.md
View File

@@ -87,9 +87,9 @@ Build-copping
* Jobs that are not in [critical e2e tests] (https://goto.google.com/k8s-test/view/Critical%20Builds/) or [flaky test builds](https://goto.google.com/k8s-test/view/Flaky/) are not your responsibility to monitor. The `Test owner:` in the job description will be automatically emailed if the job is failing.
* If you are a weekday oncall, ensure that PRs confirming to the following pre-requisites are being merged at a reasonable rate:
* [Have been LGTMd](https://github.com/kubernetes/kubernetes/labels/lgtm)
* Pass Travis and Shippable.
* Pass Travis and Jenkins per-PR tests.
* Author has signed CLA if applicable.
* If you are a weekend oncall, [never merge PRs manually](collab.md), instead add the label "lgtm" to the PRs once they have been LGTMd and passed Travis and Shippable; this will cause merge-bot to merge them automatically (or make them easy to find by the next oncall, who will merge them).
* If you are a weekend oncall, [never merge PRs manually](collab.md), instead add the label "lgtm" to the PRs once they have been LGTMd and passed Travis; this will cause merge-bot to merge them automatically (or make them easy to find by the next oncall, who will merge them).
* When the build is broken, roll back the PRs responsible ASAP
* When E2E tests are unstable, a "merge freeze" may be instituted. During a merge freeze:
* Oncall should slowly merge LGTMd changes throughout the day while monitoring E2E to ensure stability.