-
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
Pipeline as code #3552
Comments
There is also another definition of Pipeline as Code https://www.thoughtworks.com/radar/techniques/pipelines-as-code |
@stainboy I think this is more or less a duplicate of #859.
|
In addition, this is definitely a use case (Pipeline as code) Tekton components should help provide, but this is more likely outside of |
My opinion is that it will be much simpler to support a feature like this directly in tektoncd/pipeline, and at the same time I agree with @vdemeester that we should be clear about our use cases and requirements before we make any decisions, which we've been trying to hash out in #2298 |
I am very interested in that opinion because, for me, in a gist, this means that To re-make a parallel I did elsewhere, for me |
Ah interesting! @vdemeester I think you're picturing something much much more complicated than I am. Maybe that explains some of why you're pushing back in #2298? I wouldn't want to see a solution that required tektoncd/pipeline to start listening for events either. I think if you look at the example I provided in #2298 (comment) in use cases this might give you a better idea of what im imagining: allowing Pipelines to consume a repo and commitish doesn't mean that Pipelines needs to understand how those values got to it (they can be provided by triggering or by anything else). (That being said, I also don't think it would be terrible to combine triggers and pipelines into one project as I suggest in tektoncd/triggers#697 but that's another story) |
I am very happy to see that the use case has been accepted and tracked in #859. Thanks for the great work, maintainers and contributors! |
Feature request
I like the way that Jenkins works with Jenkinsfile. Normally, a Jenkinsfile is in the root directory of a Git repo, which will be dynamically located and loaded when a pipeline job is triggered by PR (or relevant events)
The changes of the PR can be either application code or Jenkinsfile. And Jenkins is always running the pipeline according to the "latest" behavior described in the Jenkinsfile.
This behavior is called "Pipeline as code".
With tekton, what I understood is we need to create the Pipeline and Trigger into Kubernetes before the PR event is triggered. Then how to dynamically alter the behavior of the Pipeline for each of the PR?
Use case
Mentioned above.
The text was updated successfully, but these errors were encountered: