Add possibility to create services in release mode#3070
Add possibility to create services in release mode#3070knative-prow-robot merged 15 commits intoknative:masterfrom
Conversation
knative-prow-robot
left a comment
There was a problem hiding this comment.
@vagababov: 0 warnings.
Details
In response to this:
For #2819
Implement@latestRevisionshorthand to be able to create releases directly in the release mode.I need integration tests, which will be either in this pr or separately.
Doc/spec update will be in separate pr./lint
-->Fixes #
Proposed Changes
- add a named target @latestRevision
- when encountered it's routed to
configuration, effectively picking the latest revision.For example:
apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: s-2 namespace: default spec: release: revisions: - "@latestRevision" configuration: revisionTemplate: spec: container: image: gcr.io/dm-vagababov/helloworld:the-one-i-love env: - name: TARGET value: "→test string←"Also /cc @sixolet @cooperneil
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
|
Also: |
|
The following is the coverage report on pkg/.
|
|
/test pull-knative-serving-go-coverage |
dgerd
left a comment
There was a problem hiding this comment.
Looks good so far. Excited to see this get merged.
Don't forget to update https://github.com/knative/serving/blob/master/docs/spec/spec.md#service with the new documentation.
Co-Authored-By: vagababov <vagababov@users.noreply.github.com>
|
@vagababov to be clear... after this PR is merged
right? |
|
Yes, the example I have above would basically behave as |
|
Great - thanks |
markusthoemmes
left a comment
There was a problem hiding this comment.
I have the same comment regarding the releaseLatestRevisionKeyword constant. Seems to me as if it should only be defined once in one place vs. twice?
I need integration tests, which will be either in this pr or separately.
Doc/spec update will be in separate pr.
Why make them seperate PRs? I don't see an integration test being super urgent here given the quite good unit-test coverage but the doc change should land with this PR imo.
|
|
spec.md updated. There wasn't a big section for release anyway. |
|
Added the comment. |
Need to get back to the old istio
|
PTAL. |
|
/lgtm |
mattmoor
left a comment
There was a problem hiding this comment.
I'd like to verify the data plane is properly configured with @latest, but otherwise this LGTM for now.
I'd also like to see more complex traffic splitting cases with @latest, but I'm ok with that in follow-up.
| ) | ||
|
|
||
| objects, err := test.CreateRunLatestServiceReady(logger, clients, &names, &test.Options{}) | ||
| objects, err := test.CreateReleaseServiceWithLatest(logger, clients, &names, &test.Options{}) |
There was a problem hiding this comment.
Can we check that this serves the expected text?
There was a problem hiding this comment.
I've added two checks. We can expand them in future, should we want to validate more fields.
|
/retest |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mattmoor, vagababov The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
* base addition to the codebase with uts * add unit test to the validation * remove debug logging * raise test coverage * Update pkg/apis/serving/v1alpha1/service_validation.go Co-Authored-By: vagababov <vagababov@users.noreply.github.com> * fix the const name * update spec.md with the new constant reference * address comments. create a globally known constant * fix the test name * go with @latest for brevity * update the conformance test * add conformance test, that validates release service creation * added more validation to the service shape
For #2819
Implement
@latestRevisionshorthand to be able to create releases directly in the release mode.I need integration tests, which will be either in this pr or separately.
Doc/spec update will be in separate pr.
/lint
-->
Fixes #
Proposed Changes
configuration, effectively picking the latest revision.For example:
/cc @dgerd @mattmoor