Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

I want to run git tag as a pipeline step, git push fails due to authencation

Edited

 

Ref  https://support.atlassian.com/bitbucket-cloud/docs/push-back-to-your-repository/

I have created a pipeline SSH key - which is used for git submodules in the repo - I created this key myself earlier today, noone else than my tasks are using this key - https://bitbucket.org/MY_COMPANY/MY_REPO_HERE/admin/addon/admin/pipelines/ssh-keys

I try to add this pipeline public SSH key to my bitbucket account, https://bitbucket.org/account/settings/ssh-keys/ 

I then get this message: 

Someone has already added that key as an access key to a repository.

my git push --tags then of course fails..

Part of my pipeline yml file below - but this fails before getting that far..

- step:
name: git tag
script:
- git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}
- git tag v$BITBUCKET_BUILD_NUMBER
- git push --tags

add_pipeline_ssh_to_personal_keys.pngpiipeline_ssh_keys.png

 

1 answer

1 accepted

0 votes
Answer accepted
Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Mar 20, 2023

Hi @Gunnar Pedersen,

An SSH key can be added as an Access Key to as many Bitbucket Cloud repos as you want. However, it is not possible to add an SSH key both as an Access key to a repo and also to the personal SSH keys of an account.

The error you see when you try to add this SSH key to your account indicates that this key is already added as an Access Key to a repository.

An Access key provides read-only access to repos, so you won't be able to push with it.

What you can do is remove this Access Key from each repository where you have added it by going to each repository's Repository settings > Acces keys. You will then be able to add it to your account's SSH keys.

If you face any issues or if you have any questions, please feel free to reach out.

Kind regards,
Theodora

Thanks for feedback Theodora.

I checked out on another repo - and I got my git tagging going there. But for the repo in question I feel that I get into a "chicken and egg" situation. The problem is that my repo has a number of git submodules that I need to fetch/update before I can start my build process. And to allow my repo to do "git submodule update --init" I need to use repo access keys in these subrepos: ref https://stackoverflow.com/questions/53121955/how-to-use-git-submodules-with-bitbucket-pipelines

Then I have to choose between using git submodules (which allows my to build my software), or git tag - but not both?


chicken_or_egg.png
Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Mar 21, 2023

Hi @Gunnar Pedersen,

You can remove the SSH key from the Access keys of the submodule repos and add it to your account. If all the submodule repos are hosted in Bitbucket Cloud, and if your account has access to all of them, then both the submodule update and the push in the next step should succeed.

We recommend using Access keys with submodules if you need read-only access in order to clone the submodules. However, it is also possible for submodules to be updated if the public SSH key is added:

  • either to an account that has access to these repos
  • or to a workspace's SSH keys, if all the repos belong to the same workspace

The first option (adding the SSH key to an account) is useful if you have branch restrictions that allow pushing only to certain accounts (this is relevant for the second step where you push).

The second option (adding the SSH key to a workspace) can be used if you don't have branch restrictions to the repo where you want to push, and if all the repos you are cloning/pushing to belong to the same workspace.

The submodules will get updated in both cases.

Please feel free to let me know how it goes and if you have any other questions!

Kind regards,
Theodora

allo again Theodora, and thanks a lot for your quick followup :-)

But I do not quite follow you, I am not sure if my account is required when compiling the software in a pipeline?

yes all the submodules are hosted in the bitbucket cloud, and yes I do have access to all the submodules from my personal account. But does that mean that the "bitbucket pipeline" job also have access to these subrepos?

I do not need to modify the submodules - only to fetch/clone them to allow my current git repo to compile.

I tried removing the ssh keys from each of the submodules repo's - and my git submodule init then failed...

submodule_init_fails.png

Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Mar 21, 2023

Hi @Gunnar Pedersen,

There is actually another simpler solution, that I missed earlier:

Use the public SSH key in the Access keys of the submodules so you can clone them.

Then, remove the following line from the second step of your yml file:

- git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}

If you remove this line, the git push command (that pushes tags) will use the HTTPS origin and you won't need to provide authentication details to push back to the repo where the build is running.

 

 

Below, I am providing more details on why what you described in your last reply did not work (you don't have to use the solution detailed below, unless for some reason you want to push back to the repo via SSH):

 

If you have generated an SSH key pair from Repository settings > SSH keys, this key pair is going to be used by default if you try to clone other Bitbucket repos via SSH or push back to the repo via SSH where the build is running.

If the public key from this SSH key pair is not added anywhere, you won't be able to clone submodules via SSH (first step of your pipeline) or push via SSH to the repo where the build is running (second step of your pipeline).

If the public key is added as an Access key to the submodules, you will be able to clone the submodules (first step of your pipeline) but you won't be able push via SSH to the repo where the build is running (second step of your pipeline). The same SSH key pair will be used for authentication in both steps.

If you add the public key

  1. either to your account (https://bitbucket.org/account/settings/ssh-keys/)
  2. or to your workspace's settings (https://bitbucket.org/workspace-id/workspace/settings/ssh-keys where workspace-id replace with the workspace id of the workspace where the repos belong to)

then both steps should succeed. You need to add the public key to one of these two places if you want to use SSH, otherwise, authentication will fail.

Please keep in mind that if you do that, the pipeline should be able to access

  • all repos your account has access to in case (1)
  • all repos belonging to the specific workspace in case (2)

This is applicable if you want to use SSH.

Kind regards,
Theodora

Finally I got it going!

I had to put back the SSH keys that I first removed (ref initial reply) - which made the git submodules init work OK again.

And then remove the line about remote origin making the git push work

Thanks for assitance, and thanks for extras on detailed solutions, which might be relevant for my next steps

Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Mar 22, 2023

That's good to hear, thank you for the update!

I also wanted to add that the second solution with SSH will work if you use the SSH origin

- git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}

I just wanted to clarify that as well, in case you ever want to use the second solution in a different step of the repo or in another repo.

Please feel free to reach out if you ever need anything else!

Like Gunnar Pedersen likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
TAGS
AUG Leaders

Atlassian Community Events