adjust newapp/newbuild error messages (arg classification vs. actual … by gabemontero · Pull Request #18272 · openshift/origin

gabemontero · 2018-01-24T18:39:56Z

…processing

@openshift/sig-developer-experience ptal

Now produces:

gmontero ~/go/src/github.com/openshift/origin  (new-app-bld-msgs)$ oc new-build --name imagesourcetest python~https://github.com/openshift-katacoda/blog-django-py --source-image xxx --source-image-path=yyy --dry-run
error: unable to locate resource for "xxx"

The 'oc new-build' command will match arguments to the following types:

  1. Images tagged into image streams in the current project or the 'openshift' project
     - if you don't specify a tag, we'll add ':latest'
  2. Images in the Docker Hub, on remote registries, or on the local Docker engine
  3. Git repository URLs or local paths that point to Git repositories

--allow-missing-images can be used to force the use of an image that was not matched

See 'oc new-build -h' for examples.

bparees · 2018-01-24T18:43:17Z

pkg/oc/cli/cmd/newapp.go

 		// only print it if we precede with classification errors, to help distinguish
 		// between the two
-		fmt.Fprintln(buf, "Errors occurred during resource creation:")
+		fmt.Fprintln(buf, "Errors occurred during %s processing of arguments:")


missing arg for %s

oh nm, i see

nope, i don't see.

ahhhh .... fix coming ....

bparees · 2018-01-24T18:51:27Z

pkg/oc/cli/cmd/newapp.go

 		// only print it if we precede with classification errors, to help distinguish
 		// between the two
-		fmt.Fprintln(buf, "Errors occurred during resource creation:")
+		fmt.Fprintf(buf, "Errors occurred during %s processing of arguments:", commandName)


can we see a sample of this new output? i'm not clear on what values "commandName" takes on

For a new-build invocation it would be:

Errors occurred during new-build processing of arguments:

where the dump of the errorGroup follows ...i.e. error: ....

substitute new-app for new-build if it comes from oc new-app ...

gabemontero · 2018-01-24T19:41:40Z

the cmd failure was a result of masking the classification error text (I was thinking there was a test for it but could not find it earlier)

some more adjustments coming ...

gabemontero · 2018-01-24T19:43:17Z

same for one of the two items noted in the integration test failure

bparees

nit and lgtm.

bparees · 2018-01-24T20:26:44Z

pkg/oc/cli/cmd/newapp.go

 		// between the two
-		fmt.Fprintln(buf, "Errors occurred during resource creation:")
+		fmt.Fprintf(buf, "Errors occurred during %s processing of arguments:", commandName)
+		fmt.Fprint(buf, "\n")


why not just put this in the Fprintf above?

will do

also, an fyi, this path is proving rare now, in that most args pass the IsComponentReference test

gabemontero · 2018-01-24T21:16:49Z

pushed changes for latest @bparees comments, as well as test adjustments for the changes in messages

bparees · 2018-01-24T21:43:39Z

test/cmd/newapp.sh

-os::cmd::expect_failure_and_text 'oc new-build https://www.google.com/openshift/nodejs-e' 'as a Git repository URL:  '
-os::cmd::expect_failure_and_text 'oc new-build https://examplegit.com/openshift/nodejs-e' 'as a Git repository URL:  '
+os::cmd::expect_failure_and_text 'oc new-app mysql-persisten mysql' 'only a partial match was found'
+os::cmd::expect_failure_and_text 'oc new-app --strategy=docker https://192.30.253.113/openshift/ruby-hello-world.git' 'only a partial match was found'


I wouldn't expect this change... feels like a step backwards from the current output:

$ oc new-app --strategy=docker https://192.30.253.113/openshift/ruby-hello-world.git error: Errors occurred while determining argument types: https://192.30.253.113/openshift/ruby-hello-world.git as a Git repository URL: fatal: unable to access 'https://192.30.253.113/openshift/ruby-hello-world.git/': SSL: no alternative certificate subject name matches target host name '192.30.253.113' https://192.30.253.113/openshift/ruby-hello-world.git as a local directory pointing to a Git repository: stat https://192.30.253.113/openshift/ruby-hello-world.git: no such file or directory Errors occurred during resource creation: error: --strategy is specified and none of the arguments provided could be classified as a source code location

(If i were to change anything about the above output, i'd skip the resource creation error output and just abort after the argument determination errors)

this change centers around my observation about the component ref classification rarely failing

I had been consider shifting my check from the classification logic (though it was more elegant) to the handleError logic ... your concern has prompted me to do that

I believe that will result in reverting the change here

One more point as a result of the shift though ... I'll be curious after I start posting some sample output if you'll want to qualify on which runtime errors the classification errors get posted.

I wonder if we'll want to reconcile the type of error noted in functions like https://github.com/openshift/origin/blob/master/pkg/oc/cli/cmd/newapp.go#L752-L878 with the output you want to see with say the invocation from @GrahamDumpleton that stemmed this issue.

I'll provide some precise examples in a bit if that helps the determination.

OK, I have a set of changes on my laptop, that if we go with, would result in:

only changing the newapp.sh test to account for the @bparees requested transition of no match for to unable to locate resource for

output of the following for @GrahamDumpleton 's example:

error: unable to locate resource for "xxx" The 'oc new-build' command will match arguments to the following types: 1. Images tagged into image streams in the current project or the 'openshift' project - if you don't specify a tag, we'll add ':latest' 2. Images in the Docker Hub, on remote registries, or on the local Docker engine 3. Git repository URLs or local paths that point to Git repositories --allow-missing-images can be used to force the use of an image that was not matched See 'oc new-build -h' for examples. For further assistance, new-build classification of argument types resulted in the following: python~https://github.com/openshift-katacoda/blog-django-py as a Git repository URL: fatal: I don't handle protocol 'python~https' python~https://github.com/openshift-katacoda/blog-django-py as a local directory pointing to a Git repository: stat python~https://github.com/openshift-katacoda/blog-django-py: no such file or directory The argument python~https://github.com/openshift-katacoda/blog-django-py passed the component classification tests

Thoughts ?

bparees · 2018-01-24T21:44:36Z

test/cmd/newapp.sh

+os::cmd::expect_failure_and_text 'oc new-app mysql-persisten mysql' 'only a partial match was found'
+os::cmd::expect_failure_and_text 'oc new-app --strategy=docker https://192.30.253.113/openshift/ruby-hello-world.git' 'only a partial match was found'
+os::cmd::expect_failure_and_text 'oc new-app https://www.google.com/openshift/nodejs-e' 'unable to lo'
+os::cmd::expect_failure_and_text 'oc new-app https://examplegit.com/openshift/nodejs-e' 'unable to lo '


similar concerns/questions on these 2.

also i think you have an extraneous space in the second one? but i'd prefer to see a lengthier text anyway, cutting it in the middle of a word is odd.

gabemontero · 2018-01-26T16:52:01Z

refactor / redirection from latest discussion thread pushed

bparees · 2018-01-26T17:45:03Z

hard for me to visualize the impact of the change, can you create some sample output?

That said, taking a step back in terms of how we can help users, I think there's a flow/filter (which i think you've sort of evolved towards):

for a given argument, could we determine its type (image, imagestream, source)
for a given argument could we match it to a resource (matched to image stream, matched to local directory, matched to remote repository, matched to a docker image)
for a given argument do we think we can access it (image is pullable, repo is cloneable)
were we able to define resources based on the arguments
were we able to create (oc create) the resources

1+2 are a bit combined today which makes this hard, of course.

gabemontero · 2018-01-26T17:47:31Z

cmd test failure https://openshift-gce-devel.appspot.com/build/origin-ci-test/pr-logs/pull/18272/test_pull_request_origin_cmd/9246/ was flake #17604

gabemontero · 2018-01-26T17:50:42Z

I suspect the gcp failure https://openshift-gce-devel.appspot.com/build/origin-ci-test/pr-logs/pull/18272/test_pull_request_origin_extended_conformance_gce/15085/ is related to all the in flight work @smarterclayton is doing with prometheus and the routers (#18245 and #18254)

gabemontero · 2018-01-26T17:57:41Z

@bparees - sure thing:

@GrahamDumpleton 's example which initiated this foray:

gmontero ~ $ oc new-build --name imagesourcetest python~https://github.com/openshift-katacoda/blog-django-py --source-image xxx --source-image-path=yyy --dry-run
error: unable to locate resource for "xxx"

The 'oc new-build' command will match arguments to the following types:

  1. Images tagged into image streams in the current project or the 'openshift' project
     - if you don't specify a tag, we'll add ':latest'
  2. Images in the Docker Hub, on remote registries, or on the local Docker engine
  3. Git repository URLs or local paths that point to Git repositories

--allow-missing-images can be used to force the use of an image that was not matched

See 'oc new-build -h' for examples.
For further assistance,  new-build classification of the argument types resulted in the following:

python~https://github.com/openshift-katacoda/blog-django-py as a Git repository URL:  fatal: I don't handle protocol 'python~https'

python~https://github.com/openshift-katacoda/blog-django-py as a local directory pointing to a Git repository:  stat python~https://github.com/openshift-katacoda/blog-django-py: no such file or directory

python~https://github.com/openshift-katacoda/blog-django-py as a template stored in a local file:  stat python~https://github.com/openshift-katacoda/blog-django-py: no such file or directory

The argument python~https://github.com/openshift-katacoda/blog-django-py passed the component classification tests

An example from the cmd tests:

gmontero ~ $ oc new-app mysql-persisten mysql
error: only a partial match was found for "mysql-persisten": "openshift/mysql-persistent"

The argument "mysql-persisten" only partially matched the following Docker image, OpenShift image stream, or template:

* Template "mysql-persistent" in project "openshift"
  Use --template="openshift/mysql-persistent" to specify this image or template


For further assistance,  new-app classification of the argument types resulted in the following:

mysql-persisten as a local directory pointing to a Git repository:  stat mysql-persisten: no such file or directory

mysql-persisten as a template stored in a local file:  stat mysql-persisten: no such file or directory

mysql as a local directory pointing to a Git repository:  stat mysql: no such file or directory

mysql as a template stored in a local file:  stat mysql: no such file or directory

The argument mysql passed the component classification tests

another cmd test example stemming from prior github issues re: confusion with the messages:

gmontero ~ $ oc new-app --strategy=docker https://192.30.253.113/openshift/ruby-hello-world.git
error: --strategy is specified and none of the arguments provided could be classified as a source code location

For further assistance,  new-app classification of the argument types resulted in the following:

https://192.30.253.113/openshift/ruby-hello-world.git as a Git repository URL:  fatal: unable to access 'https://192.30.253.113/openshift/ruby-hello-world.git/': SSL: no alternative certificate subject name matches target host name '192.30.253.113'

https://192.30.253.113/openshift/ruby-hello-world.git as a local directory pointing to a Git repository:  stat https://192.30.253.113/openshift/ruby-hello-world.git: no such file or directory

https://192.30.253.113/openshift/ruby-hello-world.git as a template stored in a local file:  stat https://192.30.253.113/openshift/ruby-hello-world.git: no such file or directory

The argument https://192.30.253.113/openshift/ruby-hello-world.git passed the component classification tests

bparees · 2018-01-26T18:03:47Z

pkg/oc/cli/cmd/newapp.go

 		fmt.Fprint(buf, group.suggestion)
 	}
+	if len(config.ArgumentClassificationErrors) > 0 && len(groups) > 0 {
+		fmt.Fprintf(buf, "\nFor further assistance,  %s classification of the argument types resulted in the following:\n", commandName)


I don't think including the cmd name in this output helps (also you've got an extra space after the comma).

I think i'd just trim it down to "Classification of arguments resulted in the following:\n"

bparees · 2018-01-26T18:05:37Z

pkg/oc/generate/app/cmd/newapp.go

+			c.ArgumentClassificationWinner = fmt.Sprintf(winnerFmt, s, "template")
+		case c.tryToAddComponentArguments(s):
+			// NOTE, component argument classification currently is the most lenient, so we save it for the end
+			c.ArgumentClassificationWinner = fmt.Sprintf(winnerFmt, s, "component")


"component" is a confusing term here...as a user when i see "the argument x passedt he component classification tests" i don't really know what that means my argument was treated as. Is there another term we can use?

bparees · 2018-01-26T18:07:56Z

pkg/oc/generate/app/cmd/newapp.go

 // AddArguments converts command line arguments into the appropriate bucket based on what they look like
 func (c *AppConfig) AddArguments(args []string) []string {
 	unknown := []string{}
+	winnerFmt := "The argument %s passed the %s classification tests"


can an argument be classified as more than one thing? if not, i'd change this to "Argument x was classified as y"

bparees · 2018-01-26T18:11:08Z

@gabemontero it seems a bit strange to me that we report that we couldn't match "xxx" to a resource, but we aren't printing any information about what "xxx" was classified(or not classified) as.

also I don't think its useful to print the classification information for arguments that we ultimately successfully classified, unless something else goes wrong.

Again breaking this down i think we should fail as early as possible and only report on the first thing we failed out on. Let users iterate their way to a correct set of args. As it stands right now, the fact that we couldn't understand "xxx" gets a bit lost w/ all the other output of the things that were not actually a problem.

gabemontero · 2018-01-26T20:38:59Z

@bparees

we do print what xxx was classified as if it was classified as something; it is possible that all the classification checks fail
we only print the classification information if there was a problem; all three of those samples I showed you were invocations that failed
on the information getting lost ... the original printing of those failed classification came from an older upstream issue around providing more information (i.e. it wasn't obvious that parameter was treated as a file that did not exist), and those newapp.sh cmd tests which were modified, when my change filtered them but you were worried we were losing functionality, stems from those .... that said, I could see perhaps only printing a) what we classified as but only when there was an error as being helpful, but again, we'll most likely have to tweak the newapp.sh accordingly.

While you percolate on that, I'll make updates per your inline PR comments and push. And can resubmit those 3 examples I posted afterward.

gabemontero · 2018-01-26T21:01:09Z

Updates on those 3 examples:

gmontero ~ $ oc new-build --name imagesourcetest python~https://github.com/openshift-katacoda/blog-django-py --source-image xxx --source-image-path=yyy --dry-run
error: unable to locate resource for "xxx"

The 'oc new-build' command will match arguments to the following types:

  1. Images tagged into image streams in the current project or the 'openshift' project
     - if you don't specify a tag, we'll add ':latest'
  2. Images in the Docker Hub, on remote registries, or on the local Docker engine
  3. Git repository URLs or local paths that point to Git repositories

--allow-missing-images can be used to force the use of an image that was not matched

See 'oc new-build -h' for examples.
Classification of arguments is the following:

python~https://github.com/openshift-katacoda/blog-django-py as a Git repository URL:  fatal: I don't handle protocol 'python~https'

python~https://github.com/openshift-katacoda/blog-django-py as a local directory pointing to a Git repository:  stat python~https://github.com/openshift-katacoda/blog-django-py: no such file or directory

python~https://github.com/openshift-katacoda/blog-django-py as a template stored in a local file:  stat python~https://github.com/openshift-katacoda/blog-django-py: no such file or directory

Argument python~https://github.com/openshift-katacoda/blog-django-py was classified as  an image reference with optionally a source repository
gmontero ~ $

gmontero ~ $ oc new-app mysql-persisten mysql
error: only a partial match was found for "mysql-persisten": "openshift/mysql-persistent"

The argument "mysql-persisten" only partially matched the following Docker image, OpenShift image stream, or template:

* Template "mysql-persistent" in project "openshift"
  Use --template="openshift/mysql-persistent" to specify this image or template


Classification of arguments is the following:

mysql-persisten as a local directory pointing to a Git repository:  stat mysql-persisten: no such file or directory

mysql-persisten as a template stored in a local file:  stat mysql-persisten: no such file or directory

mysql as a local directory pointing to a Git repository:  stat mysql: no such file or directory

mysql as a template stored in a local file:  stat mysql: no such file or directory

Argument mysql was classified as  an image reference with optionally a source repository
gmontero ~ $

gmontero ~ $ oc new-app --strategy=docker https://192.30.253.113/openshift/ruby-hello-world.git
error: --strategy is specified and none of the arguments provided could be classified as a source code location

Classification of arguments is the following:

https://192.30.253.113/openshift/ruby-hello-world.git as a Git repository URL:  fatal: unable to access 'https://192.30.253.113/openshift/ruby-hello-world.git/': SSL: no alternative certificate subject name matches target host name '192.30.253.113'

https://192.30.253.113/openshift/ruby-hello-world.git as a local directory pointing to a Git repository:  stat https://192.30.253.113/openshift/ruby-hello-world.git: no such file or directory

https://192.30.253.113/openshift/ruby-hello-world.git as a template stored in a local file:  stat https://192.30.253.113/openshift/ruby-hello-world.git: no such file or directory

Argument https://192.30.253.113/openshift/ruby-hello-world.git was classified as  an image reference with optionally a source repository
gmontero ~ $

gabemontero · 2018-01-30T15:01:47Z

@bparees and I had a chance to talk yesterday. We'll go with:

displaying the classification winner, and not losers, and adjust the tests accordingly
if nobody wins, then display how each classification failed

gabemontero · 2018-02-06T15:18:17Z

Something happened to my push with the unit/integration test fixes ... trying again

Once I have that sorted out, I'll circle back to @bparees 's #18272 (comment)

gabemontero · 2018-02-06T15:19:31Z

OK they are there now ... waiting for the tests to complete.

gabemontero · 2018-02-06T17:37:54Z

OK everything passed but cmd ... it was newapp related, but I don't understand yet why if failed. It seems like the text it was looking for was there:

test/cmd/newapp.sh:362: executing 'oc new-app --dry-run __template_fail __templatefile_fail' expecting failure and text 'for "__templatefile_fail"'
FAILURE after 0.290s: test/cmd/newapp.sh:362: executing 'oc new-app --dry-run __template_fail __templatefile_fail' expecting failure and text 'for "__templatefile_fail"': the output content test failed
There was no output from the command.
Standard error from the command:
error: unable to find the specified template: __template_fail
error: unable to locate any images in image streams, templates loaded in accessible projects, template files, local docker images with name "__template_fail"
error: unable to find the specified template file: __templatefile_fail
error: unable to locate any images in image streams, templates loaded in accessible projects, template files, local docker images with name "__templatefile_fail"

Argument '__templatefile_fail' was classified as an image reference and/or source repository.

The 'oc new-app' command will match arguments to the following types:

  1. Images tagged into image streams in the current project or the 'openshift' project
     - if you don't specify a tag, we'll add ':latest'
  2. Images in the Docker Hub, on remote registries, or on the local Docker engine
  3. Templates in the current project or the 'openshift' project
  4. Git repository URLs or local paths that point to Git repositories

--allow-missing-images can be used to point to an image that does not exist yet.

See 'oc new-app -h' for examples.

Sure enough it is failing for me now locally (had been passing I though) ... investigating

gabemontero · 2018-02-06T17:42:16Z

Ahhh ... @bparees had me replace for with with name ;-) ... fixing ....

bparees · 2018-02-06T17:46:24Z

Ahhh ... @bparees had me replace for with with name ;-) ... fixing ....

sorry :)

gabemontero · 2018-02-06T17:57:07Z

/retest

gabemontero · 2018-02-06T18:04:59Z

Something became amiss forwarding params to the remote host across the board:

++ OCT_CONFIG_HOME=/var/lib/jenkins/jobs/test_pull_request_origin_verify/workspace@3/.config
+ ssh -F ./.config/origin-ci-tool/inventory/.ssh_config openshiftdevel sudo chmod o+rw /etc/environment
Can't open user config file ./.config/origin-ci-tool/inventory/.ssh_config: No such file or directory

@dobbymoodge fyi ^^

gabemontero · 2018-02-06T22:08:10Z

ok @bparees I've made the change which will include errors for git repo access check for args ultimately classified as image, image~code, or loaded templates

give it a whirl

gabemontero · 2018-02-07T15:03:37Z

Forgot ... here are the outputs for the samples I've been posting:

gmontero ~ $ oc new-build --name imagesourcetest python~https://github.com/openshift-katacoda/blog-django-py --source-image xxx --source-image-path=yyy --dry-run
error: unable to locate any image stream images with a 'supports' annotation, images in image streams, local docker images with name "xxx"

The 'oc new-build' command will match arguments to the following types:

  1. Images tagged into image streams in the current project or the 'openshift' project
     - if you don't specify a tag, we'll add ':latest'
  2. Images in the Docker Hub, on remote registries, or on the local Docker engine
  3. Git repository URLs or local paths that point to Git repositories

--allow-missing-images can be used to force the use of an image that was not matched

See 'oc new-build -h' for examples.

gmontero ~ $ oc new-app --strategy=docker https://192.30.253.113/openshift/ruby-hello-world.git
error: --strategy is specified and none of the arguments provided could be classified as a source code location

gmontero ~ $  oc new-app ~java
error: Did not recognize the following arguments: [~java]

~java:
is not an environment variable
is not a Git repository:   local file access failed with: stat ~java: no such file or directory
is not a template stored in a local file:  stat ~java: no such file or directory
is not an image reference, image~source reference, nor template loaded in an accessible project:  when using '[image]~[code]' form for "~java", you must specify a image name


See 'oc new-app -h' for help and examples.

gmontero ~ $ oc new-app https://www.google.com/openshift/nodejs-e
error: unable to load template file "https://www.google.com/openshift/nodejs-e": unable to read URL "https://www.google.com/openshift/nodejs-e", server reported 404 Not Found, status code=404
error: git ls-remote failed with: fatal: repository 'https://www.google.com/openshift/nodejs-e/' not found;  local file access failed with: stat https://www.google.com/openshift/nodejs-e: no such file or directory
error: unable to locate any images in image streams, templates loaded in accessible projects, template files, local docker images with name "https://www.google.com/openshift/nodejs-e"

Argument 'https://www.google.com/openshift/nodejs-e' was classified as an image, image~source, or loaded template reference.

The 'oc new-app' command will match arguments to the following types:

  1. Images tagged into image streams in the current project or the 'openshift' project
     - if you don't specify a tag, we'll add ':latest'
  2. Images in the Docker Hub, on remote registries, or on the local Docker engine
  3. Templates in the current project or the 'openshift' project
  4. Git repository URLs or local paths that point to Git repositories

--allow-missing-images can be used to point to an image that does not exist yet.

See 'oc new-app -h' for examples.

gabemontero · 2018-02-07T15:58:22Z

So the unit test failure was weird. The tests passed, but 24 were skipped:

[INFO] jUnit XML report placed at _output/scripts/test-go/artifacts/gotest_report_jtnu5.xml
Of 8120 tests executed in 2816.239s, 8096 succeeded, 0 failed, and 24 were skipped.

And then it said while no failures were found, test-go.sh "failed" :

[WARNING] While the jUnit report found no failed tests, the `go test` process failed.
[WARNING] This usually means that the unit test suite failed to compile.
[ERROR] hack/test-go.sh exited with code 1 after 00h 35m 20s
make: *** [test-unit] Error 1

Will poke around and try to find out if this has been reported elsewhere.

gabemontero · 2018-02-07T15:59:34Z

gcp tests failed provisioning the test cluster

gabemontero · 2018-02-07T18:54:13Z

unit test failure is #17881

gabemontero · 2018-02-07T18:54:59Z

/test unit

bparees · 2018-02-07T18:55:37Z

barring a complete rewrite of how this arg matching+classifying logic works, i guess this is as good as it's going to get.

but please reintroduce a test around partial matches in some form.

…processing)

gabemontero · 2018-02-07T19:58:29Z

partial match test sorted out @bparees

bparees · 2018-02-07T20:01:08Z

/lgtm

openshift-ci-robot · 2018-02-07T20:01:14Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bparees, gabemontero

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these OWNERS Files:

~~pkg/oc/OWNERS~~ [bparees]
~~test/cmd/OWNERS~~ [bparees]
~~test/integration/OWNERS~~ [bparees]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

openshift-merge-robot · 2018-02-08T22:20:31Z

Automatic merge from submit-queue (batch tested with PRs 18454, 18504, 18510, 18481, 18272).

openshift-ci-robot added the sig/developer-experience label Jan 24, 2018

openshift-ci-robot requested review from csrwng and soltysh January 24, 2018 18:40

openshift-ci-robot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Jan 24, 2018

bparees reviewed Jan 24, 2018

View reviewed changes

gabemontero force-pushed the new-app-bld-msgs branch from 8f7f63f to 1805dbc Compare January 24, 2018 18:48

bparees reviewed Jan 24, 2018

View reviewed changes

gabemontero force-pushed the new-app-bld-msgs branch from 1805dbc to a6e71b7 Compare January 24, 2018 21:16

openshift-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Jan 24, 2018

bparees requested changes Jan 24, 2018

View reviewed changes

gabemontero force-pushed the new-app-bld-msgs branch from a6e71b7 to 533e96a Compare January 26, 2018 16:50

bparees requested changes Jan 26, 2018

View reviewed changes

gabemontero force-pushed the new-app-bld-msgs branch from c30f8ba to 816b5a7 Compare January 26, 2018 20:57

openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 30, 2018

gabemontero force-pushed the new-app-bld-msgs branch from 816b5a7 to 8adf826 Compare January 30, 2018 14:56

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 30, 2018

gabemontero force-pushed the new-app-bld-msgs branch from 167d81c to bafcae4 Compare February 6, 2018 15:18

gabemontero force-pushed the new-app-bld-msgs branch from bafcae4 to b51c45b Compare February 6, 2018 17:48

gabemontero force-pushed the new-app-bld-msgs branch from b51c45b to 923dce7 Compare February 6, 2018 22:06

gabemontero force-pushed the new-app-bld-msgs branch from 923dce7 to cdebd14 Compare February 7, 2018 15:01

gabemontero mentioned this pull request Feb 7, 2018

While the jUnit report found no failed tests, the go test process failed. #17881

Closed

adjust newapp/newbuild error messages (arg classification vs. actual …

2785d75

…processing)

gabemontero force-pushed the new-app-bld-msgs branch from cdebd14 to 2785d75 Compare February 7, 2018 19:58

openshift-ci-robot assigned bparees Feb 7, 2018

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Feb 7, 2018

openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 7, 2018

openshift-merge-robot merged commit 953814c into openshift:master Feb 8, 2018

gabemontero deleted the new-app-bld-msgs branch February 8, 2018 22:41

Conversation

gabemontero commented Jan 24, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gabemontero commented Jan 24, 2018

Uh oh!

gabemontero commented Jan 24, 2018

Uh oh!

bparees left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gabemontero commented Jan 24, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gabemontero commented Jan 26, 2018

Uh oh!

bparees commented Jan 26, 2018

Uh oh!

gabemontero commented Jan 26, 2018

Uh oh!

gabemontero commented Jan 26, 2018

Uh oh!

gabemontero commented Jan 26, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bparees commented Jan 26, 2018

Uh oh!

gabemontero commented Jan 26, 2018

Uh oh!

gabemontero commented Jan 26, 2018

Uh oh!

gabemontero commented Jan 30, 2018

Uh oh!

gabemontero commented Feb 6, 2018

Uh oh!

gabemontero commented Feb 6, 2018

Uh oh!

gabemontero commented Feb 6, 2018

Uh oh!

gabemontero commented Feb 6, 2018

Uh oh!

bparees commented Feb 6, 2018

Uh oh!

gabemontero commented Feb 6, 2018

Uh oh!

gabemontero commented Feb 7, 2018 •

edited

Loading