* fix(issue #762): correct error message when updating service
* correct message when updating service and passing many names
* fix issue with TestServiceUpdateWithMultipleImages running create vs update
* * added TestServiceDescribeWithMultipleNames
* added TestServiceCreateWithMultipleNames
* fix error message for service delete since many names can be passed
When specified on 'service create' the '--cluster-local' flag will
make the created service 'private' by setting its config visibility
to 'cluster-local'. This is done with label:
serving.knative.dev/visibility: cluster-local
The --no-cluster-local will remove the label.
* Fix --image flag to only allow single occurence
* Fix changelog link
* Reflect feedback in error message and type name
* Add unit tests
* Reflect unit tests improvement from feedback
* Fix unit tests due to changes in master
Inferring the `sync` param from `fakeServiceUpdate` and `fakeServiceCreate` by the
parameter `--no-wait`.
Simplifies the UTs and also avoids a nasty NPE if the sync param was not (in sync :)
with the `--no-wait` flag.
* feature(serving): Update API to serving.knative.dev/v1
Due to an issue with 0.12.0 (a missing constant) the update also includes an update
to the latest knative-serving and knative-eventing dependencies from master
(as reflected in version.go)
Signed-off-by: Roland Huß <roland@ro14nd.de>
* fix(serving): Bogus import removed
* fix(serving): Add missing go.sum entry
* Vendors serving v0.9.0
* Updates references per serving v0.9.0 vendoring
- Updates code and tests to refer the required data structure and method/function calls
- duckv1beta1 -> duckv1 conditions
- traffic percent value is now *int64
- containerConcurrency validation method relocation
* fix(golint): exported function should have comment
for NonReadyConditionReason function
* Updates check for removing null targets
fixes the pointer value check
* Updates per review comments
* Increased default timeout to 600s. This timeout will be triggered
only when the Ready condition stays in UNKNOWN for that long. If its
True or False then the command will return anyway sooner.
So it makes sense to go for a much longer timeout than 60s
* Enhanced output to indicate the progress
This change needs some updates to the API and introduces a 'MessageCallback'
type which is calle for each intermediate event with the "Ready" condition message.
Markus Thömmes