-
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 values for type
s in resources
#54
Conversation
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bobcatfish The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
we will rebase this once its merged and can resolve any conflicts, there are a lot of good clean up here /lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can have a generic interface for result store to make extensible, with runs, logs and tests as implementations of this interface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the TaskTriggerRef
idea a lot. This is critical information for an operator to know the cause of task run. Great addition.
My Canadian 2 cents: Is ResultTarget
a good candidate for interface. Defining the expected behavior rather than restricting it to uploading to a destination. One use case I can think of would be an operator desire to dump logs in DB.
/lgtm
Rest looks great. Awesome work 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
For sure @shashwathi I think that makes a lot of sense and is definitely relevant to @tejal29 's interests as well :D
But we don't even have pennies anymore 😭 |
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
andTaskTriggerType
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
andArtifactType
into one type as well. (Sorry @pivotal-nader-ziada and @shashwathithis will probably cause some conflicts with your changes but hopefully they'll
be minor to resolve! Lemme know if I can help or if you want me to hold off)
While doing this noticed and cleaned up a couple things:
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
(such as
zz_generated.deepcopy.go
)Fixes #18