|
|
|
CI session
|
|
|
|
==========
|
|
|
|
|
|
|
|
- We should *only* merge code where the CI is not failing.
|
|
|
|
- We should consider having the test-network-all tests running as well as stem
|
|
|
|
tests.
|
|
|
|
- Sometimes consensus might fail because of the way we fire off timers eagerly.
|
|
|
|
- Cascading failure modes for consensus, we might happen for the public
|
|
|
|
network, but it's more unlikely.
|
|
|
|
- Let's start by having it as allow to fail tests on Travis while we test it.
|
|
|
|
|
|
|
|
- We should put high priority to always fixing CI failures.
|
|
|
|
- We should ensure CI passes before we merge more stuff.
|
|
|
|
- Should we have asn/dgoulet create PR's as part of the review ticket triage:
|
|
|
|
yes, we do, but only for a test period where they note down how much time
|
|
|
|
they spend.
|
|
|
|
- CI/coverity role creates a ticket when there is CI failure and tries to
|
|
|
|
ensure that it gets assigned to the right people (subsystem maintainer).
|
|
|
|
- Create ticket when a test has been disabled due to CI failures. Review the
|
|
|
|
list of tickets at the upcoming network-team meeting.
|
|
|
|
- AppVeyor is currently broken.
|
|
|
|
- If we don't watch AppVeyor we should watch jenkins for Windows' failures.
|
|
|
|
- For volunteers either put their code in a PR and/or put the ticket into needs_info
|
|
|
|
|
|
|
|
- Rationales for CI:
|
|
|
|
- When CI is broken on master, it's a lot of work to figure out if it's
|
|
|
|
master or your own branch that is the problem. |
