Skip to content
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

Run taskRun without a Task by adding TaskSpec #262

Merged
merged 4 commits into from
Nov 29, 2018

Conversation

nader-ziada
Copy link
Member

@nader-ziada nader-ziada commented Nov 23, 2018

Fixes #249

Proposed Changes

  • Add a TaskSpec field to the TaskRun which is mutually exclusive with taskRef
  • validation for not having taskRef and taskSpec together but having one of them
  • Changed TaskRef field in taskRun to a pointer now that's optional
  • Unit tests for running TaskRun without a task
    if TaskSpec includes sources it doesn't need to be defined as a Resource

now with this feature, users can run TaskRun without a task as demonstrated by the following example:

apiVersion: pipeline.knative.dev/v1alpha1
kind: PipelineResource
metadata:
  name: go-example-git
spec:
  type: git
  params:
  - name: url
    value: https://github.com/pivotal-nader-ziada/gohelloworld
---
apiVersion: pipeline.knative.dev/v1alpha1
kind: TaskRun
metadata:
  name: build-push-task-run-2
spec:
  trigger:
    triggerRef:
      type: manual
  inputs:
    resources:
    - name: workspace
      resourceRef:
        name: go-example-git
  taskSpec: 
    inputs:
      resources:
      - name: workspace
        type: git    
    steps:
    - name: build-and-push
      image: gcr.io/kaniko-project/executor
      command:
      - /kaniko/executor
      args:
      - --destination=gcr.io/my-project/gohelloworld

@knative-prow-robot knative-prow-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Nov 23, 2018
@knative-prow-robot knative-prow-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 23, 2018
Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One comment, otherwise looks good 👼

}
return validateTaskRunAndTask(c, *tr, t, tr.Namespace)
return nil
Copy link
Member

@vdemeester vdemeester Nov 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we validate it in that case too ? 🤔

This would require to change the signature of validateTaskRunTask though, but most likely for the good

// […]
    return validateTaskRunAndTask(c, *tr, t.Spec, tr.Namespace)
}
return validateTaskRunAndTask(c, *tr, tr.TaskSpec, tr.Namespace)

(On that note, thinking outloud, we only validate the spec, so we may want to pass only the specs — the tr.Name is only required on the error message, so we could use github.com/pkg/errors to wrap errors and thus adding the tr.Name via the caller)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point, I should add that

Copy link
Contributor

@shashwathi shashwathi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend updating taskrun test(kaniko) or pipelinerun e2e test to include a taskrun which has inlined taskspec. WDYT @pivotal-nader-ziada ?

pkg/apis/pipeline/v1alpha1/taskrun_validation.go Outdated Show resolved Hide resolved
Copy link
Collaborator

@bobcatfish bobcatfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments from pair review with @pivotal-nader-ziada :

  • leaning toward not supporting sources in this initial PR
  • need some docs on how to use this

Name: "myarg",
Description: "mydesc",
Default: "mydefault",
}},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like maybe we DO support params! i cant see a strong reason not support them esp. if we get it for free

pkg/reconciler/v1alpha1/taskrun/taskrun_test.go Outdated Show resolved Hide resolved
@nader-ziada
Copy link
Member Author

@bobcatfish addressed the comments, ready for another look

taskSpec = taskRun.Spec.TaskSpec
taskName = taskRun.Name
} else {
return taskSpec, taskName, fmt.Errorf("TaskRun %s not providing TaskRef or TaskSpec", taskRun.Name)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this happens to be the only line not covered by the unit tests and i actually wonder if we need it at all - at this point, we do happen to know that the taskSpec has been validated, and there should be no case like this

however maybe its safer to keep it - im fine with not covering the line in unit tests :D

@bobcatfish
Copy link
Collaborator

Looks great to me! Thanks for adding the docs also ^.^

/lgtm

I'm going to add a hold here b/c @imjasonh opened the issue and might have some opinions about us removing sources

/hold

/meow space

@knative-prow-robot knative-prow-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 28, 2018
@knative-prow-robot
Copy link

@bobcatfish: cat image

In response to this:

Looks great to me! Thanks for adding the docs also ^.^

/lgtm

I'm going to add a hold here b/c @imjasonh opened the issue and might have some opinions about us removing sources

/hold

/meow space

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.

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 28, 2018
Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

3. Another way of running a Task is embedding the TaskSpec in the taskRun yaml as shown in the following example

```yaml
apiVersion: pipeline.knative.dev/v1alpha1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we still need to create two resources to run a simple set of steps? How can we drop the requirement that a PipelineResource already exists?

In Build, resources were specified directly in the build itself, as source(s).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, we felt this would be an acceptable compromise so its not too different from the rest of the pipeline project and confusing for users

Copy link
Collaborator

@bobcatfish bobcatfish Nov 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can we drop the requirement that a PipelineResource already exists?

One option @pivotal-nader-ziada and I talked about was embedding the Resource spec inside the resource field in the TaskRun, e.g.:

  inputs:
    resources:
    - name: workspace
      resourceSpec:
        type: git
        params:
        - name: url
           value: https://github.com/pivotal-nader-ziada/gohelloworld

This is kinda the direction @shashwathi is going in #270 as well, where we can use the TaskRunResource to provide a path where the resource will be located in a PVC.

We'd need to actually create an instance of the Resource probably, so we can extend Resources generically (#238)

@imjasonh would you like to see something like that in this PR or a follow up PR?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think adding even more embedding is just making the yaml file too complicated. Also one side benefit is that the resources are such a core concept in build-pipeline that we want users to know about when migrating.

Maybe as part of the work for the resources extensibility we can make this easier by making the taskRun controller create the resource for for system supported resource types such as git. In that case, the we can define types for system resources with their specific fields to simplify yaml files for all tasks

Depending on what we decide here, how big the change is, it might be better to have another follow up PR so this one doesn't get too big

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think adding even more embedding is just making the yaml file too complicated. Also one side benefit is that the resources are such a core concept in build-pipeline that we want users to know about when migrating.

That's a good point!

Depending on what we decide here, how big the change is, it might be better to have another follow up PR so this one doesn't get too big

Sounds good to me

inputs:
resources:
- name: workspace
type: git
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This type is specified twice, once in the type of the workspace resource (line 194) and again here. Can one be removed? What happens if the resource is type:foo but I specify it as an input with type:bar ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the runtime validation in the controller would give an error about the resource type. The reason its defined twice is that its usually in two different objects, task and taskRun, and we were trying to use the existing code and types

// can't have both taskRef and taskSpec at the same time
if (ts.TaskRef != nil && ts.TaskRef.Name != "") && ts.TaskSpec != nil {
fields := []string{"spec.taskref", "spec.taskspec"}
return apis.ErrDisallowedFields(fields...)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should work:

return apis.ErrDisallowedFields("spec.taskref", "spec.taskspec")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I can change that one


// Check that one of TaskRef and TaskSpec is present
if (ts.TaskRef == nil || (ts.TaskRef != nil && ts.TaskRef.Name == "")) && ts.TaskSpec == nil {
fields := []string{"spec.taskref.name", "spec.taskspec"}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will also change it

@nader-ziada
Copy link
Member Author

/hold cancel

since I made a small fix and rebased which removed the lgtm

@knative-prow-robot knative-prow-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 29, 2018
@imjasonh
Copy link
Member

/lgtm

Sounds like there are some more streaming changes we should make, but those definitely don't belong in this PR.

Thanks for doing this work Nader, this should definitely improve the basic getting-started experience, and will make Serving usage simpler, once we get there.

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 29, 2018
- users can specifiy TaskRef or TaskSpec, but not both
- update type
- add validation and tests
- update taskRef everywhere to be a pointer since its now optional

Signed-off-by: Nader Ziada <nziada@pivotal.io>
- remove support for using sources in the taskSpec
- use TaskResolver
- refactor tests

Signed-off-by: Nader Ziada <nziada@pivotal.io>
Signed-off-by: Nader Ziada <nziada@pivotal.io>
@knative-prow-robot knative-prow-robot removed the lgtm Indicates that a PR is ready to be merged. label Nov 29, 2018
@knative-metrics-robot
Copy link

The following is the coverage report on pkg/.
Say /test pull-knative-build-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/pipeline/v1alpha1/taskrun_validation.go 93.1% 93.3% 0.2
pkg/reconciler/v1alpha1/taskrun/resources/taskrunresolution.go 100.0% 96.6% -3.4
pkg/reconciler/v1alpha1/taskrun/taskrun.go 74.1% 72.2% -1.9

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 29, 2018
@knative-prow-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pivotal-nader-ziada, vdemeester

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:
  • OWNERS [pivotal-nader-ziada]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@knative-prow-robot knative-prow-robot merged commit 3076f41 into tektoncd:master Nov 29, 2018
@nader-ziada nader-ziada deleted the run-task branch February 13, 2019 14:02
pradeepitm12 pushed a commit to pradeepitm12/pipeline that referenced this pull request Jan 28, 2021
This makes it safe to remove triggers from a cluster without impacting
the shared pipelines namespace.

Fixes tektoncd#262.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants