-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add enum like values for all type
placeholders
#18
Comments
bobcatfish
referenced
this issue
in bobcatfish/pipeline
Sep 17, 2018
Added values for the following types, which would be the initial types we would want to implement and support (could expand to support more in the future): - `SourceType` - `ArtifactType` - `ResultTargetType` - `PipelineTriggerType` and `TaskTriggerType` - `ParamType` (just strings for now?) Since in #39 @pivotal-nader-ziada and @shashwathi are combining Sources and Artifacts into one concept, we'll likely combine `SourceType` and `ArtifactType` into one type as well. While doing this noticed and cleaned up a couple things: - Don't need to specify lists of result stores, just one for each type (test, log, runs). Also these are identical except for their usage, so we can use a common type for all of them - Turns out pipeline run specs were not defined! - Updated DEVELOPMENT.md re. how to regenerate generated code (such as `zz_generated.deepcopy.go`) Fixes #18
knative-prow-robot
pushed a commit
that referenced
this issue
Sep 18, 2018
Added values for the following types, which would be the initial types we would want to implement and support (could expand to support more in the future): - `SourceType` - `ArtifactType` - `ResultTargetType` - `PipelineTriggerType` and `TaskTriggerType` - `ParamType` (just strings for now?) Since in #39 @pivotal-nader-ziada and @shashwathi are combining Sources and Artifacts into one concept, we'll likely combine `SourceType` and `ArtifactType` into one type as well. While doing this noticed and cleaned up a couple things: - Don't need to specify lists of result stores, just one for each type (test, log, runs). Also these are identical except for their usage, so we can use a common type for all of them - Turns out pipeline run specs were not defined! - Updated DEVELOPMENT.md re. how to regenerate generated code (such as `zz_generated.deepcopy.go`) Fixes #18
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected Behavior
Whenever a
type
attribute is used, there should be string aliases for all the possible value values so we can see what values should be possible. This should just include the types we would initially expect to implement.Actual Behavior
There are a bunch of places in our API where we use a
type
attribute, but it's not clear what kinds of values should actually be used for these, for example https://github.com/knative/build-pipeline/blob/ef113e1d513c67b692eb1096904789be0e9616b6/pkg/apis/pipeline/v1beta1/pipelineparams_types.go#L35Additional Info
According to k8s API conventions we should not use enums, but should use string constants instead, e.g. see knative/serving
ServiceConditionType
The text was updated successfully, but these errors were encountered: