* add run as user flag #678
* add run as user flag #678
* add changelog for pr 679
* review comments for pr 679
* review comments for pr 679
* add test for config changes
* add user 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
* Add support for envFrom, volumeMounts, serviceAccountName, and imagePullPolicy
* Add comments for added functions
* Add test functions for --env-from
* Add test functions for --volume-mount
* Add test functions for --service-account-name and --image-pull-policy
* Add testing functions to cover the case "service update --env-from"
* Add test functions to cover the case "service update --volume-mount"
* Add missing test functions for config_changes.go
* Add testing functions for pkg/util/parsing_helper.go
* Fix a bug on a test case, caused by ignoring random orderedness of map
* Remove image-pull-policy because it is not supported by Knative
* Fix comments to clarify it as well as to fix a typo
* Remove service-account-name flags in order to submit it as a seperate PR
* Split --volume-mount flag into --volume-mount and --volume flags in order to enable multiple times mounting for the same volume
* Change the name of local variable to simplify
* Update docs
* Change the flag "--volume-mount" into "--mount", and fix it to make volume automatically when the config-map or secret is directley used. In addition, the test cases are changed to new unit test style. To keep the original orderedness given via flags, OrderedMap implementation is added as well
* Fix usage descriptions for the mount flag
* Factor out the name existence checking from createEnvFromSource
* Fix the usage description for --mount
* Sanitize a generated volume name
* 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.
Murugappan Chetty