March 2018 - tor-commits - lists.torproject.org

[tor/release-0.3.3] Document how to allow partial Travis failures
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit 09484b944993f4b8d0a43ecedabeb2c86f889b77 Author: Taylor Yu <catalyst(a)torproject.org> Date: Wed Feb 28 12:28:45 2018 -0600 Document how to allow partial Travis failures Add some commented-out allow_failures clauses to make it easier to temporarily allow less-critical sub-builds to fail while still reporting success. --- .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/.travis.yml b/.travis.yml index 60f82af3f..3f125f275 100644 --- a/.travis.yml +++ b/.travis.yml @@ -62,10 +62,26 @@ env: - MAKEFLAGS="-j 2" matrix: - ## If one build in the matrix fails (e.g. if building withour Rust and Clang - ## fails, but building with Rust and GCC is still going), then cancel the - ## entire job early and call the whole thing a failure. - fast_finish: true + ## Uncomment to allow the build to report success (with non-required + ## sub-builds continuing to run) if all required sub-builds have + ## succeeded. This is somewhat buggy currently: it can cause + ## duplicate notifications and prematurely report success if a + ## single sub-build has succeeded. See + ## https://github.com/travis-ci/travis-ci/issues/1696 + # fast_finish: true + + ## Uncomment the appropriate lines below to allow the build to + ## report success even if some less-critical sub-builds fail and it + ## seems likely to take a while for someone to fix it. Currently + ## Travis CI doesn't distinguish "all builds succeeded" from "some + ## non-required sub-builds failed" except on the individual build's + ## page, which makes it somewhat annoying to detect from the + ## branches and build history pages. See + ## https://github.com/travis-ci/travis-ci/issues/8716 + allow_failures: + # - env: RUST_OPTIONS="--enable-rust" TOR_RUST_DEPENDENCIES=true + # - env: RUST_OPTIONS="--enable-rust --enable-cargo-online-mode + # - compiler: clang ## Create explicit matrix entries to work around a Travis CI ## environment issue. Missing keys inherit from the first list

1 0

[tor/release-0.3.3] Merge branch 'maint-0.2.9' into maint-0.3.1
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit 1aa0ae2cc3547a35a44967ed56c1f78a42c076f8 Merge: 0e7f15fdb 3370b3cfe Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 19 05:42:43 2018 -0400 Merge branch 'maint-0.2.9' into maint-0.3.1 .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --cc .travis.yml index 19bbe6df0,6d314c141..d6450d270 --- a/.travis.yml +++ b/.travis.yml @@@ -60,19 -60,28 +60,35 @@@ env global: ## The Travis CI environment allows us two cores, so let's use both. - MAKEFLAGS="-j 2" + matrix: + ## Leave at least one entry here or Travis seems to generate a + ## matrix entry with empty matrix environment variables. Leaving + ## more than one entry causes unwanted matrix entries with + ## unspecified compilers. + - RUST_OPTIONS="--enable-rust --enable-cargo-online-mode" + # - RUST_OPTIONS="" matrix: - ## If one build in the matrix fails (e.g. if building withour Rust and Clang - ## fails, but building with Rust and GCC is still going), then cancel the - ## entire job early and call the whole thing a failure. - fast_finish: true + ## Uncomment to allow the build to report success (with non-required + ## sub-builds continuing to run) if all required sub-builds have + ## succeeded. This is somewhat buggy currently: it can cause + ## duplicate notifications and prematurely report success if a + ## single sub-build has succeeded. See + ## https://github.com/travis-ci/travis-ci/issues/1696 + # fast_finish: true + + ## Uncomment the appropriate lines below to allow the build to + ## report success even if some less-critical sub-builds fail and it + ## seems likely to take a while for someone to fix it. Currently + ## Travis CI doesn't distinguish "all builds succeeded" from "some + ## non-required sub-builds failed" except on the individual build's + ## page, which makes it somewhat annoying to detect from the + ## branches and build history pages. See + ## https://github.com/travis-ci/travis-ci/issues/8716 + allow_failures: + # - env: RUST_OPTIONS="--enable-rust" TOR_RUST_DEPENDENCIES=true + # - env: RUST_OPTIONS="--enable-rust --enable-cargo-online-mode + # - compiler: clang ## Create explicit matrix entries to work around a Travis CI ## environment issue. Missing keys inherit from the first list

1 0

[tor/release-0.3.3] Merge branch 'maint-0.3.2' into maint-0.3.3
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit 85719b79b71eb5a4ef889272a393aa97bbc86134 Merge: 9d1c7c3a8 bc0de600b Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 19 05:42:43 2018 -0400 Merge branch 'maint-0.3.2' into maint-0.3.3 .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.2' into release-0.3.2
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit 36154c13f41f517c7629613d4b58cde23bb9ee1a Merge: 75b544d64 bc0de600b Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 19 05:42:43 2018 -0400 Merge branch 'maint-0.3.2' into release-0.3.2 .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.1' into maint-0.3.2
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit bc0de600b2033c6fb109d70ff3cbd8b8dc2ad271 Merge: a0cc7e949 1aa0ae2cc Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 19 05:42:43 2018 -0400 Merge branch 'maint-0.3.1' into maint-0.3.2 .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)

1 0

[tor/maint-0.3.2] Merge remote-tracking branch 'catalyst-github/bug25388-025' into maint-0.2.5
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit 0eb2cdf99de77556fce549ba856887d5852a034b Merge: 3418a3a7f 09484b944 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 19 05:42:38 2018 -0400 Merge remote-tracking branch 'catalyst-github/bug25388-025' into maint-0.2.5 .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)

1 0

[tor/maint-0.3.2] Document how to allow partial Travis failures
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit 09484b944993f4b8d0a43ecedabeb2c86f889b77 Author: Taylor Yu <catalyst(a)torproject.org> Date: Wed Feb 28 12:28:45 2018 -0600 Document how to allow partial Travis failures Add some commented-out allow_failures clauses to make it easier to temporarily allow less-critical sub-builds to fail while still reporting success. --- .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/.travis.yml b/.travis.yml index 60f82af3f..3f125f275 100644 --- a/.travis.yml +++ b/.travis.yml @@ -62,10 +62,26 @@ env: - MAKEFLAGS="-j 2" matrix: - ## If one build in the matrix fails (e.g. if building withour Rust and Clang - ## fails, but building with Rust and GCC is still going), then cancel the - ## entire job early and call the whole thing a failure. - fast_finish: true + ## Uncomment to allow the build to report success (with non-required + ## sub-builds continuing to run) if all required sub-builds have + ## succeeded. This is somewhat buggy currently: it can cause + ## duplicate notifications and prematurely report success if a + ## single sub-build has succeeded. See + ## https://github.com/travis-ci/travis-ci/issues/1696 + # fast_finish: true + + ## Uncomment the appropriate lines below to allow the build to + ## report success even if some less-critical sub-builds fail and it + ## seems likely to take a while for someone to fix it. Currently + ## Travis CI doesn't distinguish "all builds succeeded" from "some + ## non-required sub-builds failed" except on the individual build's + ## page, which makes it somewhat annoying to detect from the + ## branches and build history pages. See + ## https://github.com/travis-ci/travis-ci/issues/8716 + allow_failures: + # - env: RUST_OPTIONS="--enable-rust" TOR_RUST_DEPENDENCIES=true + # - env: RUST_OPTIONS="--enable-rust --enable-cargo-online-mode + # - compiler: clang ## Create explicit matrix entries to work around a Travis CI ## environment issue. Missing keys inherit from the first list

1 0

[tor/maint-0.3.2] Merge branch 'maint-0.2.5' into maint-0.2.9
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit 3370b3cfef62cba8377285d95b232f810edde504 Merge: 67a313f0e 0eb2cdf99 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 19 05:42:43 2018 -0400 Merge branch 'maint-0.2.5' into maint-0.2.9 .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)

1 0

[tor/maint-0.3.3] Document how to allow partial Travis failures
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit 09484b944993f4b8d0a43ecedabeb2c86f889b77 Author: Taylor Yu <catalyst(a)torproject.org> Date: Wed Feb 28 12:28:45 2018 -0600 Document how to allow partial Travis failures Add some commented-out allow_failures clauses to make it easier to temporarily allow less-critical sub-builds to fail while still reporting success. --- .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/.travis.yml b/.travis.yml index 60f82af3f..3f125f275 100644 --- a/.travis.yml +++ b/.travis.yml @@ -62,10 +62,26 @@ env: - MAKEFLAGS="-j 2" matrix: - ## If one build in the matrix fails (e.g. if building withour Rust and Clang - ## fails, but building with Rust and GCC is still going), then cancel the - ## entire job early and call the whole thing a failure. - fast_finish: true + ## Uncomment to allow the build to report success (with non-required + ## sub-builds continuing to run) if all required sub-builds have + ## succeeded. This is somewhat buggy currently: it can cause + ## duplicate notifications and prematurely report success if a + ## single sub-build has succeeded. See + ## https://github.com/travis-ci/travis-ci/issues/1696 + # fast_finish: true + + ## Uncomment the appropriate lines below to allow the build to + ## report success even if some less-critical sub-builds fail and it + ## seems likely to take a while for someone to fix it. Currently + ## Travis CI doesn't distinguish "all builds succeeded" from "some + ## non-required sub-builds failed" except on the individual build's + ## page, which makes it somewhat annoying to detect from the + ## branches and build history pages. See + ## https://github.com/travis-ci/travis-ci/issues/8716 + allow_failures: + # - env: RUST_OPTIONS="--enable-rust" TOR_RUST_DEPENDENCIES=true + # - env: RUST_OPTIONS="--enable-rust --enable-cargo-online-mode + # - compiler: clang ## Create explicit matrix entries to work around a Travis CI ## environment issue. Missing keys inherit from the first list

1 0

[tor/maint-0.3.2] Merge branch 'maint-0.2.9' into maint-0.3.1
by nickm＠torproject.org 19 Mar '18

19 Mar '18

commit 1aa0ae2cc3547a35a44967ed56c1f78a42c076f8 Merge: 0e7f15fdb 3370b3cfe Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 19 05:42:43 2018 -0400 Merge branch 'maint-0.2.9' into maint-0.3.1 .travis.yml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --cc .travis.yml index 19bbe6df0,6d314c141..d6450d270 --- a/.travis.yml +++ b/.travis.yml @@@ -60,19 -60,28 +60,35 @@@ env global: ## The Travis CI environment allows us two cores, so let's use both. - MAKEFLAGS="-j 2" + matrix: + ## Leave at least one entry here or Travis seems to generate a + ## matrix entry with empty matrix environment variables. Leaving + ## more than one entry causes unwanted matrix entries with + ## unspecified compilers. + - RUST_OPTIONS="--enable-rust --enable-cargo-online-mode" + # - RUST_OPTIONS="" matrix: - ## If one build in the matrix fails (e.g. if building withour Rust and Clang - ## fails, but building with Rust and GCC is still going), then cancel the - ## entire job early and call the whole thing a failure. - fast_finish: true + ## Uncomment to allow the build to report success (with non-required + ## sub-builds continuing to run) if all required sub-builds have + ## succeeded. This is somewhat buggy currently: it can cause + ## duplicate notifications and prematurely report success if a + ## single sub-build has succeeded. See + ## https://github.com/travis-ci/travis-ci/issues/1696 + # fast_finish: true + + ## Uncomment the appropriate lines below to allow the build to + ## report success even if some less-critical sub-builds fail and it + ## seems likely to take a while for someone to fix it. Currently + ## Travis CI doesn't distinguish "all builds succeeded" from "some + ## non-required sub-builds failed" except on the individual build's + ## page, which makes it somewhat annoying to detect from the + ## branches and build history pages. See + ## https://github.com/travis-ci/travis-ci/issues/8716 + allow_failures: + # - env: RUST_OPTIONS="--enable-rust" TOR_RUST_DEPENDENCIES=true + # - env: RUST_OPTIONS="--enable-rust --enable-cargo-online-mode + # - compiler: clang ## Create explicit matrix entries to work around a Travis CI ## environment issue. Missing keys inherit from the first list

1 0