Make it easier to extract content from hack/env#10458
Make it easier to extract content from hack/env#10458openshift-bot merged 1 commit intoopenshift:masterfrom
Conversation
| go: | ||
| - 1.6 | ||
| - tip | ||
| - 1.7 |
There was a problem hiding this comment.
I thought you argued to keep tip?
There was a problem hiding this comment.
Basically tip gets unstable after a release - probably half way through 1.8
we'll turn tip on. Otherwise would be failing all the time.
On Tue, Aug 16, 2016 at 12:41 PM, Steve Kuznetsov notifications@github.com
wrote:
In .travis.yml
#10458 (comment):@@ -2,7 +2,7 @@ language: go
go:
- 1.6
- tip
- 1.7
I thought you argued to keep tip?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openshift/origin/pull/10458/files/4b046250753fe0e53bf15c100edb397d81ac6315#r74972318,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pwAOcjhcjIDk_08kGQixr2ueJzNVks5qgehHgaJpZM4Jlmyi
.
There was a problem hiding this comment.
Like it is now
There was a problem hiding this comment.
you could always do
go:
- 1.6
- 1.7
- tip
matrix:
fast_finish: true
allow_failures:
- go: tipand just toggle off allowing failures on tip mid-release
keeps travis green, lets you see tip status easily (see #10472 / https://travis-ci.org/openshift/origin/builds/152847351)
There was a problem hiding this comment.
I think tip is going to be bad for a while, and we don't care about tip much yet.
There was a problem hiding this comment.
I feel like Jordan's approach is probably better so that people who care can look at the errors on tip and file upstream bugs as necessary, helps us all be part of a good open source community and all that jazz
There was a problem hiding this comment.
|
Addressed comment [merge] |
hack/common.sh
Outdated
|
|
||
| # extract content from the image | ||
| if [[ -n "${OS_BUILD_ENV_PRESERVE}" ]]; then | ||
| local workingdir="$(docker inspect -f '{{ index . "Config" "WorkingDir" }}' "${container}")" |
There was a problem hiding this comment.
Sorry, didn't see this before. You never want to do scoping (local, export) in the same line as anything else with a return code since the return code of the "other thing" - your sub shell expansion here and below for parent - will be aliased masked by the return code of the scoping statement, which is basically always 0.
|
[test] |
|
Proto test was not running cleanly, not sure why that changed. |
OS_BUILD_ENV_PRESERVE=_output/local/releases hack/env make release Allows content to be extracted back to the working dir (relative) after a build.
|
Evaluated for origin test up to 82402c7 |
|
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/8078/) |
|
[merge] |
|
Evaluated for origin merge up to 82402c7 |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/8078/) (Image: devenv-rhel7_4864) |
|
[merge] |
|
@danmcp re: editing comments ... look at what we see above. it makes no sense. |
|
@stevekuznetsov Because the merge request is after the merge comment? We changed a while back to recreate on a few cases. Namely on failures to make sure people got emails. I don't mind making the success comment also recreate. It would just mean more emails for people. |
|
Yes, because the timeline doesn't make sense -- we should be recreating in this case. |
|
@stevekuznetsov Actually I remembered now why I didn't before. You already get an email from GitHub on merge. So it would be redundant. Wasn't sure it was worth it to get the comment moved down. Still debating. |
|
I don't like optimizing for e-mail over the web interface ... the merge tests succeeding and the merge happening are two distinct occurrences. |
5 participants
OS_BUILD_ENV_PRESERVE=_output/local/releases hack/env make release
Allows content to be extracted back to the working dir (relative) after
a build.
[test] @stevekuznetsov for bashisms
fixes #10445 by removing tip from travis matrix