I don't seem to be able to reproduce it, could you provide more info?

$ oc version
oc v1.0.5-67-gc9cb0b6
kubernetes v1.1.0-alpha.0-1605-g44c91b1

$ oc new-app --docker-image=openshift/ruby-20-centos7\~https://github.com/openshift/ruby-hello-world --name=myapp 
imagestreams/ruby-20-centos7
imagestreams/myapp
buildconfigs/myapp
deploymentconfigs/myapp
services/myapp
WARNING: We created an image stream "myapp", but it does not look like a Docker registry has been integrated with the server. Automatic builds and deployments depend on that integration to detect new images and will not function properly.
Build "myapp" created and started - you can run `oc status` to check the progress.
Service "myapp" created at 172.30.98.73 with port mappings 8080.
Run 'oc status' to view your app.

Not sure what can I say more, perhaps it could be related to the underlying environment?
> [fedora@akostadi-fedora22-client ~]$ oc version
> oc v1.0.5
> kubernetes v1.1.0-alpha.0-1605-g44c91b1
> [fedora@akostadi-fedora22-client ~]$ oc new-project asdfg
> Now using project "asdfg" on server "https://openshift-137.example.com:8443".
> [fedora@akostadi-fedora22-client ~]$ oc new-app --docker-image=openshift/ruby-20-centos7\~https://github.com/openshift/ruby-hello-world --name=myapp 
> imagestreams/ruby-20-centos7
> imagestreams/myapp
> Error: BuildConfig "myapp" is invalid: triggers[2].type: invalid value 'ConfigChange': invalid trigger type
> deploymentconfigs/myapp
> services/myapp

This is from the underlying environment:
> [root@openshift-137 ~]# openshift version
> openshift v3.0.1.0-528-g8c2fe51
> kubernetes v1.0.0

Ben / Cesar, any clue here?

This happens when I run it against OSE.3.x using 1.0.5 (or 1.0.4).  I don't see the error when I run the same test against an EC2 instance.

Here's more information on what we tried.

oc version  | client platform   |  master platform | status |
1.0.4       | Mac               |   OSE            |   F    |
1.0.4       | Linux             |   OSE            |   P    |
1.0.5       | Mac               |   OSE            |   F    |
1.0.5       | Linux             |   OSE            |   F    |

All passed when run against EC2 (devenv-fedora_xxx)

From the above test matrix, it looks like there are some differences between the client verison for Mac vs Linux as well.

ConfigChange is definitely a new trigger that was introduced, so i can understand the server side not recognizing it, but it should ignore it..I guess our validation rules were a bit aggressive.

I'm not sure what we can do now...the only viable fix would be for the client tools to know what version of the backend they are talking to (And not just an api version) and not add the ConfigChange trigger if they are talking to an older server that is going to fail the validation.

Clayton, how bad did we mess up here? :)

related:
https://github.com/openshift/origin/issues/4447

The OSE version has this version information.
[root@openshift-138 ~]# oc version
oc v3.0.1.0-528-g8c2fe51
kubernetes v1.0.0

Not a fix for existing OSE versions, but in the future we'll be less strict about validating trigger names when this gets merged:

https://github.com/openshift/origin/pull/4556

It will allow new triggers to be added without breaking old versions of servers.

*** Bug 1259263 has been marked as a duplicate of this bug. ***

we discussed this on the bug scrub today and the proposed solution is to catch the validation failure in new-app and then recreate the buildconfig without the trigger and resubmit it.

PR https://github.com/openshift/origin/pull/4613

PR #2: https://github.com/openshift/origin/pull/4635

Verified with b0a2fa5 client against
> openshift v3.0.1.900-185-g2f7757a

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days