-
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
Implement simple PipelineRun #61
Comments
@bobcatfish Was looking at if there is a way to divide this further.
On the branch, i went ahead and added all the methods
We could potentially see if |
Added the beginnings of a skeleton of an integration test for PipelineRun for #61. In doing this I realized that I couldn't creating PipelineParam objects with the clients b/c the plural name was wrong - it needs to be `pipelineparamses` like I'm Smeagol. Meanwhile refactored the existing controller code to break some code out of the Reconciler, so it can be instantiated without an entire controller (just depends on the objects it needs). The decision about what TaskRuns to create has been separated from the logic to retrieve existing ones, and the logic to create them. (`GetTasks`, `getNextPipelineRunTaskRun`) The tests were refactored such that the success cases are in separate tests from the failure cases, so the table driven tests dont have to handle both and it's more clear what the tests are doing.
Added the beginnings of a skeleton of an integration test for PipelineRun for #61. In doing this I realized that I couldn't create PipelineParam objects with the clients b/c the plural name was wrong - it needs to be `pipelineparamses` like I'm Smeagol. I tried to work around this and stumbled on kubernetes/code-generator#53 so it doesn't seem to be possible without changing the code-generator code :( Meanwhile refactored the existing controller code to break some code out of the Reconciler, so it can be instantiated without an entire controller (instead depends only on the objects it needs). The decision about what TaskRuns to create has been separated from the logic to retrieve existing ones, and the logic to create them. (`GetTasks`, `getNextPipelineRunTaskRun`) The tests were refactored such that the success cases are in separate tests from the failure cases, so the table driven tests dont have to handle both and it's more clear what the tests are doing.
Added the beginnings of a skeleton of an integration test for PipelineRun for #61. In doing this I realized that I couldn't create PipelineParam objects with the clients b/c the plural name was wrong - it needs to be `pipelineparamses` like I'm Smeagol. I tried to work around this and stumbled on kubernetes/code-generator#53 so it doesn't seem to be possible without changing the code-generator code :( Meanwhile refactored the existing controller code to break some code out of the Reconciler, so it can be instantiated without an entire controller (instead depends only on the objects it needs). The decision about what TaskRuns to create has been separated from the logic to retrieve existing ones, and the logic to create them. (`GetTasks`, `getNextPipelineRunTaskRun`) The tests were refactored such that the success cases are in separate tests from the failure cases, so the table driven tests dont have to handle both and it's more clear what the tests are doing.
Added logic to check statuses of other TaskRuns when deciding if a new one should be started for #61
Added logic to check statuses of other TaskRuns when deciding if a new one should be started for #61
PipelineRun status will be based on the condition of the TaskRuns which it has created, for #61. If any TaskRuns have failed, the PipelineRun has failed. If all are successful, it is successful. If any are in progress, it is in progress. This is assuming a linear Pipeline, we will have to tweak this a bit when we implement the graph (for #65)
Added the Task reference to the TaskRun so that when a PipelineRun creates a TaskRun, it actually executes! (For #61) While running the integration test, noticed that the PipelineRuns weren't getting reconciled quickly enough, but adding a tracker which will invoke reconcile when the created TaskRuns are updated fixed this - however it did still take > 1 minute to create 3 helloworld TaskRuns and wait for them to complete, so since 3 was arbitrary, reduced to 2. Also cleaned up the TaskRun controller a bit: using the Logger object on the controller/reconciler itself, made the log messages a bit more descriptive.
Added the Task reference to the TaskRun so that when a PipelineRun creates a TaskRun, it actually executes! (For #61) While running the integration test, noticed that the PipelineRuns weren't getting reconciled quickly enough, but adding a tracker which will invoke reconcile when the created TaskRuns are updated fixed this - however it did still take > 1 minute to create 3 helloworld TaskRuns and wait for them to complete, so since 3 was arbitrary, reduced to 2. Also cleaned up the TaskRun controller a bit: using the Logger object on the controller/reconciler itself, made the log messages a bit more descriptive.
Added the Task reference to the TaskRun so that when a PipelineRun creates a TaskRun, it actually executes! (For #61) While running the integration test, noticed that the PipelineRuns weren't getting reconciled quickly enough, but adding a tracker which will invoke reconcile when the created TaskRuns are updated fixed this - however it did still take > 1 minute to create 3 helloworld TaskRuns and wait for them to complete, so since 3 was arbitrary, reduced to 2. Also cleaned up the TaskRun controller a bit: using the Logger object on the controller/reconciler itself, made the log messages a bit more descriptive.
Added logic to check statuses of other TaskRuns when deciding if a new one should be started for #61
PipelineRun status will be based on the condition of the TaskRuns which it has created, for #61. If any TaskRuns have failed, the PipelineRun has failed. If all are successful, it is successful. If any are in progress, it is in progress. This is assuming a linear Pipeline, we will have to tweak this a bit when we implement the graph (for #65)
Added the Task reference to the TaskRun so that when a PipelineRun creates a TaskRun, it actually executes! (For #61) While running the integration test, noticed that the PipelineRuns weren't getting reconciled quickly enough, but adding a tracker which will invoke reconcile when the created TaskRuns are updated fixed this - however it did still take > 1 minute to create 3 helloworld TaskRuns and wait for them to complete, so since 3 was arbitrary, reduced to 2. Also cleaned up the TaskRun controller a bit: using the Logger object on the controller/reconciler itself, made the log messages a bit more descriptive.
Added the Task reference to the TaskRun so that when a PipelineRun creates a TaskRun, it actually executes! (For #61) While running the integration test, noticed that the PipelineRuns weren't getting reconciled quickly enough, but adding a tracker which will invoke reconcile when the created TaskRuns are updated fixed this - however it did still take > 1 minute to create 3 helloworld TaskRuns and wait for them to complete, so since 3 was arbitrary, reduced to 2. Also cleaned up the TaskRun controller a bit: using the Logger object on the controller/reconciler itself, made the log messages a bit more descriptive.
Added logic to check statuses of other TaskRuns when deciding if a new one should be started for #61
PipelineRun status will be based on the condition of the TaskRuns which it has created, for #61. If any TaskRuns have failed, the PipelineRun has failed. If all are successful, it is successful. If any are in progress, it is in progress. This is assuming a linear Pipeline, we will have to tweak this a bit when we implement the graph (for #65)
Added the Task reference to the TaskRun so that when a PipelineRun creates a TaskRun, it actually executes! (For #61) While running the integration test, noticed that the PipelineRuns weren't getting reconciled quickly enough, but adding a tracker which will invoke reconcile when the created TaskRuns are updated fixed this - however it did still take > 1 minute to create 3 helloworld TaskRuns and wait for them to complete, so since 3 was arbitrary, reduced to 2. Also cleaned up the TaskRun controller a bit: using the Logger object on the controller/reconciler itself, made the log messages a bit more descriptive.
Added logic to check statuses of other TaskRuns when deciding if a new one should be started for #61
PipelineRun status will be based on the condition of the TaskRuns which it has created, for #61. If any TaskRuns have failed, the PipelineRun has failed. If all are successful, it is successful. If any are in progress, it is in progress. This is assuming a linear Pipeline, we will have to tweak this a bit when we implement the graph (for #65)
Added the Task reference to the TaskRun so that when a PipelineRun creates a TaskRun, it actually executes! (For #61) While running the integration test, noticed that the PipelineRuns weren't getting reconciled quickly enough, but adding a tracker which will invoke reconcile when the created TaskRuns are updated fixed this - however it did still take > 1 minute to create 3 helloworld TaskRuns and wait for them to complete, so since 3 was arbitrary, reduced to 2. Also cleaned up the TaskRun controller a bit: using the Logger object on the controller/reconciler itself, made the log messages a bit more descriptive.
Expected Behavior
A user should be able to create a
PipelineRun
which will look at theTasks
in the referencedPipeline
and for each of those, create aTaskRun
.If #59 is done before this, creation of the
TaskRun
would also trigger running of theTask
, however if not, nothing would actually be executed but theTaskRuns
would exist.Out of scope of this issue (coming in later issues):
Requirements:
Actual Behavior
If you create a
PipelineRun
, nothing will happen.Steps to Reproduce the Problem
Task
like this:Pipeline
like this:PipelineRun
like this:TaskRuns
, so we should then be able to see:a. The
status
of thePipelineRun
should be updated (see example), check withkubectl get pipelineRuns
b. There should be 3
TaskRuns
created, each with a unique name and a reference to thePipelineRun
(check withkubectl get taskRuns
), for example:(I left the PipelineParams reference out of the PipelineRun, but if it turns out that we need a ServiceAccount to make this work, we'll need to specify it in the PipelineParams and reference it in the PipelineRun as well)
The text was updated successfully, but these errors were encountered: