You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 14, 2023. It is now read-only.
I am using the task during an application build stage in a multi-stage pipeline. The pipeline defines a "pipeline resource" to download during deployment stages, containing configuration.
Expected behavior
Since the pipeline yaml is part of the application sources, we expect the task to tag the git repository where our pipeline resides. Eg the repository that the build stage clones at the very beginning aka the current repo!
NB this behavior is what we get when we create pipelines containing only the build stage.
Observed behavior
The task is now tagging the repository, that contains the pipeline, that produced the pipeline resource we described (configuration).
Let this sink in for a second here.
It is tagging the repo, of a pipeline resource artifact. Not the application repo we just checked out.
Is there a way to enforce tagging the current "working" repository?
The text was updated successfully, but these errors were encountered:
I also struggled with this issue. The workaround is to change resources.pipeline.YOUR_RESOURCE_NAME.sourceProvider before the tag and then set it back to the correct state after (in my case it is TfsGit). It is not perfect but it works. I hope this issue will be fixed soon.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I am using the task during an application build stage in a multi-stage pipeline. The pipeline defines a "pipeline resource" to download during deployment stages, containing configuration.
Expected behavior
Since the pipeline yaml is part of the application sources, we expect the task to tag the git repository where our pipeline resides. Eg the repository that the build stage clones at the very beginning aka the current repo!
NB this behavior is what we get when we create pipelines containing only the build stage.
Observed behavior
The task is now tagging the repository, that contains the pipeline, that produced the pipeline resource we described (configuration).
Let this sink in for a second here.
It is tagging the repo, of a pipeline resource artifact. Not the application repo we just checked out.
Is there a way to enforce tagging the current "working" repository?
The text was updated successfully, but these errors were encountered: