I already have pipeline triggers between repositories working without any issues.
Now, I have a new custom pipeline in a third repo (all are in the same workspace). In my existing repo where I already have a pipeline trigger for a custom pipeline, when I call the new pipeline, I keep getting "Account, repository or branch doesn't exist."
This new pipeline works perfectly when I run it manually from its repo. I copy / pasted the repo name, branch and pipeline names. All repos in the workspace use the same SSH key.
In the following, &chart step works but &deploy-cdk doesn't. What am I missing? They are pretty similar except for the number of variables. I tried adding ACCOUNT variable with workspace name, removing BRANCH_NAME (target repo only has "main" branch), nothing works.
- step: &chart # Update Helm chart in non production flow. ** Assumes a chart is present
name: Update helm chart value with the build number
script:
- cat tag.sh
- source tag.sh
- pipe: atlassian/trigger-pipeline:5.0.0
variables:
BITBUCKET_USERNAME: '${BB_PIPE_USER}'
BITBUCKET_APP_PASSWORD: '${BB_PIPE_PW}'
REPOSITORY: 'microservices-charts'
BRANCH_NAME: 'master'
CUSTOM_PIPELINE_NAME: 'update-k8s-values'
PIPELINE_VARIABLES: >
[{
"key": "REPO_SLUG",
"value": "${BITBUCKET_REPO_SLUG}"
},
{
"key": "IMAGE_TAG",
"value": "${IMAGE_TAG}"
},
{
"key": "VACV_ENV",
"value": "dev"
}]
WAIT: 'true'
- step: &deploy-cdk
name: deploy CDK
script:
- echo "Commit hash is ${BITBUCKET_COMMIT}"
- pipe: atlassian/trigger-pipeline:5.0.0
variables:
BITBUCKET_USERNAME: '${BB_PIPE_USER}'
BITBUCKET_APP_PASSWORD: '${BB_PIPE_PW}'
REPOSITORY: 'packages-spa-deployment'
BRANCH_NAME: 'main'
CUSTOM_PIPELINE_NAME: 'dev-build'
PIPELINE_VARIABLES: >
[{
"key": "BUILD_HASH",
"value": "${BITBUCKET_COMMIT}"
}]
WAIT: 'true'
DEBUG: 'true'
pipelines:
custom:
dev-build:
- variables:
- name: BUILD_HASH
- step:
name: log commit hash
script:
- echo "Updating dev bucket with latest commit $BUILD_HASH"
- step: *build-cdk
- step: *cdk-deploy-np
@François Collinshi. The problem is that you use wrong configuration in bitbucket-pipeline.yml.
In this version of pipe 5.0.0
It should be:
REF_TYPE: 'branch'
REF_NAME: 'main'
BRANCH_NAME: 'main'
according to documentation.
Congratulations! You nailed it.
It didn't happen on any other pipe trigger when I upgraded the version, it seems to work anyway with the previous syntax. However, since my colleague happened to name the main (and only) branch "main" in this specific scenario, it caused confusion.
The other pipe triggers still work because in the other repos we reference, the main branch is called "master". Subtle.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@François Collins hi. Can you try to add ACCOUNT to pipe according to example into your &deploy-cdk step:
Basic example. This pipe will trigger the branch pipeline for master
in your-awesome-repo
that is owned by the teams-in-space
Bitbucket account.
script: - pipe: atlassian/trigger-pipeline:5.0.0 variables: BITBUCKET_USERNAME: $BITBUCKET_USERNAME BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD REPOSITORY: 'your-awesome-repo' ACCOUNT: 'teams-in-space'
The default is $BITBUCKET_REPO_OWNER, but maybe you have different account in that workspace.
Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I already tried that and it didn't make any difference. Besides, we only have one workspace, and Mark C stated that it's only required if you're referencing a pipeline in a different workspace.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@François Collinshi. I see that you have branch master in microservices-charts, and branch main in packages-spa-deployment from your configuration yml file. Is this correct? Maybe the problem is you need to trigger master branch in packages-spa-deployment?
Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Mark C, can you state on whether a pipeline in repo 1 can only be called remotely in repo 2 if pipeline 2 SSH is the same user that created repo 1?
If not, what would explain that pipeline 2 SSH (which is admin user) cannot access the remote pipeline in repo 1 if everything else is the same?
All repos in workspace are using the same admin user SSH in pipeline settings in order to be able to clone other repos.
To restate:
Repo 1 -> manual run of custom pipeline -> works
Repo 2 -> pipe -> custom pipeline in repo 3 -> works
Repo 2 -> pipe -> custom pipeline in repo 1 -> does not work
Create repo 4 with exact same setup as repo 1 but creator is admin, copy files from repo1, test that custom pipeline runs within its repo
Repo 2 -> pipe -> pipeline in repo 4 -> works after changing just the repo name in pipe variables.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @François Collins
Using the Pipes script (atlassian/trigger-pipeline) shouldn't be dependent on any SSH key since it's authenticating through HTTPS via username and app password.
For us to continue to investigate the issue further, I've gone ahead and raised a support ticket for this.
You should receive an email notification about it and let's continue our investigation there.
Regards,
Mark C
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Welcome to the community.
If the repository is under the same workspace where you've run the Pipes script (atlassian/trigger-pipeline:5.0.0), it's fine not to include the variable "ACCOUNT" but if it's from another workspace, you'll have to include it
For the repository (packages-spa-deployment), would you be able to confirm if Pipelines is enabled there and if the file "bitbucket-pipelines.yml" exists in the main branch?
Thanks and let me know how it goes.
Regards,
Mark C
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
They are all in the same workspace, packages-spa-deployment has the yaml file, it only has main branch, and as I mentioned it works when I run it from within the repo.
I couldn't figure out what was different between packages-spa-deployment and the other repo from where I can successfully call another pipeline (SSH keys, access, variables, branch permissions, etc), they seemed identical to me. The surrogate user in the pipeline SSH is supposed to have administrator access to all repos.
So as a last resort, I created a new repo alltogether while logged on as the same user as the SSH, copied the files from packages-spa-deployment into this new repo, redid the same setup as the original, and now everything works. I can call the pipeline in the copied repo.
It looks like the target repo must have been created by the same user that calls it remotely. This is annoying, because I need to call several pipe triggers from the same repo. Fortunately at the moment they were all created by the same admin user, but it might not always be the case.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @François Collins
Thanks for that info.
Is there a chance the repository (packages-spa-deployment) is a forked repository?
Regards,
Mark C
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.