The reproduce for this behaviour is to follow https://github.com/rhd-gitops-example/services/tree/master/tekton-example and do the first PipelineRun creation, then the second TaskRun creation.
You'll notice that for the service-promote Task, we get a pull request mentioning a local filesystem.
I believe this is because we clone the project to the workspace Tekton uses so it's not a valid URL (it's, for example, /workspace/git-app-repo and not https://github.com/myorg/repo.git), and thus we assume the user is going down a local promotion path.
This isn't what I expected though, I thought it would be a promote from repository X to repository Y.
The problem PR: https://github.com/a-roberts/gitops-test/pull/2
And not a problem PR (from repo to repo), you get a-roberts/gitops-repo-testing#1 which is better.
Note, I've opened an issue to use exemplar repositories (both in terms of name and contents) for the Tekton example at #68.
The reproduce for this behaviour is to follow https://github.com/rhd-gitops-example/services/tree/master/tekton-example and do the first PipelineRun creation, then the second TaskRun creation.
You'll notice that for the
service-promoteTask, we get a pull request mentioning a local filesystem.I believe this is because we clone the project to the workspace Tekton uses so it's not a valid URL (it's, for example, /workspace/git-app-repo and not https://github.com/myorg/repo.git), and thus we assume the user is going down a local promotion path.
This isn't what I expected though, I thought it would be a promote from repository X to repository Y.
The problem PR: https://github.com/a-roberts/gitops-test/pull/2
And not a problem PR (from repo to repo), you get a-roberts/gitops-repo-testing#1 which is better.
Note, I've opened an issue to use exemplar repositories (both in terms of name and contents) for the Tekton example at #68.