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

Implement working "hello world" Task + TaskRun #59

Closed
bobcatfish opened this issue Sep 21, 2018 · 3 comments
Closed

Implement working "hello world" Task + TaskRun #59

bobcatfish opened this issue Sep 21, 2018 · 3 comments

Comments

@bobcatfish
Copy link
Collaborator

bobcatfish commented Sep 21, 2018

Expected Behavior

A user should be able to create a "hello world" Task that just echoes "hello world" and run it as many times as they like in their k8s cluster by creating TaskRuns.

Requirements:

Actual Behavior

It is possible to get something like this working with Build only, but currently our TaskRun controller does nothing.

Steps to Reproduce the Problem

  1. Deploy the Pipeline CRD + related CRDs to your cluster (note: should be docs on how to do this post kubebuilder)
  2. Create a task like this:
apiVersion: pipeline.knative.dev/v1beta1
kind: Task
metadata:
  name: helloworld-task
  namespace: default
spec:
    buildSpec:
        steps:
            - name: helloworld
              image: busybox
              args: ['echo', 'hello world'']
  1. Create a task run like this:
apiVersion: pipeline.knative.dev/v1beta1
kind: TaskRun
metadata:
  name: helloworld-task-run-0
spec:
    taskRef:
        name: helloworld-task
    trigger:
        triggerRef:
            type: manual
  1. Look at the logs from the running container (Note the best docs we have on this at the moment are some of the steps in the Build quick start) - these should contain "hello world"
  2. Observe that the status of the TaskRun has been updated appropriately, e.g. see this example which contains:
  • Outcomes of individual steps
  • Started, Completed, and Successful conditions
@nader-ziada
Copy link
Member

in the example above, in step (3) should the name of TaskRef be helloworldTask as indicated by the name defined for the task in step (2)
or is that name coming from somewhere else?

@bobcatfish
Copy link
Collaborator Author

in the example above, in step (3) should the name of TaskRef be helloworldTask as indicated by the name defined for the task in step (2)
or is that name coming from somewhere else?

Oh whoops, so in step (3) I think the name should be helloworld-task since that's what the Task is called. Thanks for catching that @pivotal-nader-ziada ! I've updated it, let me know if it still doesn't seem right.

bobcatfish referenced this issue in bobcatfish/pipeline Oct 5, 2018
This is a WIP of adding an integration test to cover #59, which is a
simple TaskRun which has no inputs or outputs but just runs a container
that echoes helloworld.

At this point we have the logic to:
- Create the Task and TaskRun
- Wait for the TaskRun to have a condition (TODO: actually check the
  conditions, waiting to rebase onto #86)
- Get the Build associated (not yet created, will be via #86)
- Get the Pod for the build
- TODO: get the logs for that Pod (we've been looking at
  https://github.com/knative/build/blob/e8c2cb6eb5cb09d9737ca9e6da4a1c68af3247b2/pkg/logs/logs.go#L36:6
  for inspiration)

This also changes namespaces to be test specific, so each test can
create a namespace and tear it down, without needing to keep track of
resources created and delete them individually.
bobcatfish referenced this issue in bobcatfish/pipeline Oct 5, 2018
This is a WIP of adding an integration test to cover #59, which is a
simple TaskRun which has no inputs or outputs but just runs a container
that echoes helloworld.

At this point we have the logic to:
- Create the Task and TaskRun
- Wait for the TaskRun to have a condition (TODO: actually check the
  conditions, waiting to rebase onto #86)
- Get the Build associated (not yet created, will be via #86)
- Get the Pod for the build
- TODO: get the logs for that Pod (we've been looking at
  https://github.com/knative/build/blob/e8c2cb6eb5cb09d9737ca9e6da4a1c68af3247b2/pkg/logs/logs.go#L36:6
  for inspiration)

This also changes namespaces to be test specific, so each test can
create a namespace and tear it down, without needing to keep track of
resources created and delete them individually.
bobcatfish referenced this issue in bobcatfish/pipeline Oct 5, 2018
This is a WIP of adding an integration test to cover #59, which is a
simple TaskRun which has no inputs or outputs but just runs a container
that echoes helloworld.

At this point we have the logic to:
- Create the Task and TaskRun
- Wait for the TaskRun to have a condition (TODO: actually check the
  conditions, waiting to rebase onto #86)
- Get the Build associated (not yet created, will be via #86)
- Get the Pod for the build
- TODO: get the logs for that Pod (we've been looking at
  https://github.com/knative/build/blob/e8c2cb6eb5cb09d9737ca9e6da4a1c68af3247b2/pkg/logs/logs.go#L36:6
  for inspiration)

This also changes namespaces to be test specific, so each test can
create a namespace and tear it down, without needing to keep track of
resources created and delete them individually.

Also had to change some optional resources to be pointers, because json
marshalling will still require optional fields to be present if they are
not nullable
(https://stackoverflow.com/questions/18088294/how-to-not-marshal-an-empty-struct-into-json-with-go)
bobcatfish referenced this issue in bobcatfish/pipeline Oct 5, 2018
This is a WIP of adding an integration test to cover #59, which is a
simple TaskRun which has no inputs or outputs but just runs a container
that echoes helloworld.

At this point we have the logic to:
- Create the Task and TaskRun
- Wait for the TaskRun to have a condition (TODO: actually check the
  conditions, waiting to rebase onto #86)
- Get the Build associated (not yet created, will be via #86)
- Get the Pod for the build
- TODO: get the logs for that Pod (we've been looking at
  https://github.com/knative/build/blob/e8c2cb6eb5cb09d9737ca9e6da4a1c68af3247b2/pkg/logs/logs.go#L36:6
  for inspiration)

This also changes namespaces to be test specific, so each test can
create a namespace and tear it down, without needing to keep track of
resources created and delete them individually.
bobcatfish referenced this issue in bobcatfish/pipeline Oct 5, 2018
This is a WIP of adding an integration test to cover #59, which is a
simple TaskRun which has no inputs or outputs but just runs a container
that echoes helloworld.

At this point we have the logic to:
- Create the Task and TaskRun
- Wait for the TaskRun to have a condition (TODO: actually check the
  conditions, waiting to rebase onto #86)
- Get the Build associated (not yet created, will be via #86)
- Get the Pod for the build
- TODO: get the logs for that Pod (we've been looking at
  https://github.com/knative/build/blob/e8c2cb6eb5cb09d9737ca9e6da4a1c68af3247b2/pkg/logs/logs.go#L36:6
  for inspiration)

This also changes namespaces to be test specific, so each test can
create a namespace and tear it down, without needing to keep track of
resources created and delete them individually.
bobcatfish referenced this issue in bobcatfish/pipeline Oct 5, 2018
This is a WIP of adding an integration test to cover #59, which is a
simple TaskRun which has no inputs or outputs but just runs a container
that echoes helloworld.

At this point we have the logic to:
- Create the Task and TaskRun
- Wait for the TaskRun to have a condition (TODO: actually check the
  conditions, waiting to rebase onto #86)
- Get the Build associated (not yet created, will be via #86)
- Get the Pod for the build
- TODO: get the logs for that Pod (we've been looking at
  https://github.com/knative/build/blob/e8c2cb6eb5cb09d9737ca9e6da4a1c68af3247b2/pkg/logs/logs.go#L36:6
  for inspiration)

This also changes namespaces to be test specific, so each test can
create a namespace and tear it down, without needing to keep track of
resources created and delete them individually.

Co-authored-by: Aaron Prindle <aprindle@google.com>
bobcatfish referenced this issue in bobcatfish/pipeline Oct 5, 2018
This is a WIP of adding an integration test to cover #59, which is a
simple TaskRun which has no inputs or outputs but just runs a container
that echoes helloworld.

At this point we have the logic to:
- Create the Task and TaskRun
- Wait for the TaskRun to have a condition (TODO: actually check the
  conditions, waiting to rebase onto #86)
- Get the Build associated (not yet created, will be via #86)
- Get the Pod for the build
- TODO: get the logs for that Pod (we've been looking at
  https://github.com/knative/build/blob/e8c2cb6eb5cb09d9737ca9e6da4a1c68af3247b2/pkg/logs/logs.go#L36:6
  for inspiration)

This also changes namespaces to be test specific, so each test can
create a namespace and tear it down, without needing to keep track of
resources created and delete them individually.

Co-authored-by: Aaron Prindle <aprindle@google.com>
bobcatfish referenced this issue in bobcatfish/pipeline Oct 5, 2018
This is a WIP of adding an integration test to cover #59, which is a
simple TaskRun which has no inputs or outputs but just runs a container
that echoes helloworld.

At this point we have the logic to:
- Create the Task and TaskRun
- Wait for the TaskRun to have a condition (TODO: actually check the
  conditions, waiting to rebase onto #86)
- Get the Build associated (not yet created, will be via #86)
- Get the Pod for the build
- TODO: get the logs for that Pod (we've been looking at
  https://github.com/knative/build/blob/e8c2cb6eb5cb09d9737ca9e6da4a1c68af3247b2/pkg/logs/logs.go#L36:6
  for inspiration)

This also changes namespaces to be test specific, so each test can
create a namespace and tear it down, without needing to keep track of
resources created and delete them individually.

Co-authored-by: Aaron Prindle <aprindle@google.com>
knative-prow-robot pushed a commit that referenced this issue Oct 5, 2018
This is a WIP of adding an integration test to cover #59, which is a
simple TaskRun which has no inputs or outputs but just runs a container
that echoes helloworld.

At this point we have the logic to:
- Create the Task and TaskRun
- Wait for the TaskRun to have a condition (TODO: actually check the
  conditions, waiting to rebase onto #86)
- Get the Build associated (not yet created, will be via #86)
- Get the Pod for the build
- TODO: get the logs for that Pod (we've been looking at
  https://github.com/knative/build/blob/e8c2cb6eb5cb09d9737ca9e6da4a1c68af3247b2/pkg/logs/logs.go#L36:6
  for inspiration)

This also changes namespaces to be test specific, so each test can
create a namespace and tear it down, without needing to keep track of
resources created and delete them individually.

Co-authored-by: Aaron Prindle <aprindle@google.com>
knative-prow-robot pushed a commit that referenced this issue Oct 8, 2018
This pr implements a simple TaskRun controller that creates a knative/build Build and updates the TaskRun status to reflect the Build status. We delegate to the knative/build controller to do the work of actually fulfillign the Build itself - meaning we have a hard dependency on knative/build.

The integration test doesn't actually assert on the logs output by the
bulid step because the pods disappear immediately after completion, so
we need a better solution here (e.g. writing to a PVC in the test) - in
the long run we need to implement better log support (#107).

Remaining work for #59 is to improve unit test coverage, and add some
docs on running + debugging.
@aaron-prindle
Copy link
Contributor

fixed with #86

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants