We’re transitioning from OAuth to Personal Access Tokens (PATs) for our source control provider integrations with Bitbucket and GitHub. If you are using Bitbucket or GitHub, you need to re-authenticate using PAT to avoid build failures. This change offers several benefits that will be valuable for you and your projects.
Why Personal Access Tokens
Advanced Security: Your security is our top priority. PATs offer a more robust and secure way to connect with your source control repositories. Unlike OAuth tokens, which can grant broad access, PATs allow for precise, fine-grained control.
Empowerment: With PATs, you can specify the precise permissions Build Automation has when interacting with your repositories. Whether it’s read-only access or limiting specific actions, you’re in control.
Simplified Management: Should you ever need to modify permissions or revoke access, PATs offer a streamlined process. Managing tokens is easy, allowing you to adjust your access settings as needed.
How to Transition to Personal Access Tokens
Transitioning is easy, and here’s how to do it:
Log in to the dashboard
Visit DevOps → Build Automation → Settings → Source Control
Select your source control provider
Create a new Personal Access Token within your Bitbucket or GitHub account and copy it to your clipboard
Paste this token into the designated field and click Authorize or Re-authorize
Select your repository from the list and click Save
It’s a simple process and should only take a moment. Should you have any questions or require assistance during the transition, our support team is here to help.
Required Bitbucket Permissions
If your source control of choice is Bitbucket, at a minimum read access is required in order to checkout and build your project.
However, it is recommended to add Read & Write permissions for Webhooks in order to support builds on changes to source code.
Required GitHub Permissions
If your source control of choice is GitHub, at a minimum read access is required in order to checkout and build your project.
However, it is recommended to add Write permissions in order to support builds on changes to source code.
I followed the instructions for the Bitbucket setup and everything looked fine until I started a build and get these errors:
[2023-11-08T17:54:31.589Z] - 7.3.26.2.7.4 - INFO: GIT: Checking out via URI...
[2023-11-08T17:54:31.589Z] - 7.3.26.2.7.4 - INFO: Attempt 1 of 5 to clone repository.
[error] [2023-11-08T17:54:34.293Z] - 7.3.26.2.7.4 - ERROR: /cygdrive/c/tools/cygwin/bin/gitc.exe clone '--branch' 'develop' '--recursive' '--' 'https:****2:*****@' 'BUILD_PATH/p/' 2>&1:Cloning into 'BUILD_PATH/p'...
ssh: Could not resolve hostname https: Name or service not known
[error] fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
[error] Git::GitExecuteError (/cygdrive/c/tools/cygwin/bin/gitc.exe clone '--branch' 'develop' '--recursive' '--' 'https:****2:*****@' 'BUILD_PATH/p/' 2>&1:Cloning into 'BUILD_PATH/p'...
ssh: Could not resolve hostname https: Name or service not known
[error] fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.):
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/git-1.5.0/lib/git/lib.rb:967:in `command'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/git-1.5.0/lib/git/lib.rb:77:in `clone'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/git-1.5.0/lib/git/base.rb:29:in `clone'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/git-1.5.0/lib/git.rb:97:in `clone'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/bvr-7.3.26.2.7.4/lib/source-control/managers/****/checkout.rb:77:in `clone_with_retry'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/bvr-7.3.26.2.7.4/lib/source-control/managers/****/checkout.rb:58:in `clone'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/bvr-7.3.26.2.7.4/lib/source-control/managers/****/****_scm.rb:48:in `checkout'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/bvr-7.3.26.2.7.4/lib/source-control/source_control_manager.rb:30:in `checkout'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/bvr-7.3.26.2.7.4/lib/source-control/cli.rb:44:in `checkout'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/thor-0.19.4/lib/thor/command.rb:27:in `run'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/thor-0.19.4/lib/thor/invocation.rb:126:in `invoke_command'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/thor-0.19.4/lib/thor.rb:369:in `dispatch'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/thor-0.19.4/lib/thor/base.rb:444:in `start'
/home/buildbot/.rvm/gems/ruby-2.7.4/gems/bvr-7.3.26.2.7.4/bin/source-control:11:in `<main>'
I’m unable to build using PAT. Could you check if this is a problem on Cloud Build’s side?
Would have been pretty nice to have gotten an email and not just a notification that all my builds failed.
By the way for anyone who uses submodules, I hope they’re a part of your organization because (at least on bitbucket) if you have bitbucket premium you can get an organization level access token which lets you access your submodules.
If you don’t have premium or are using submodules from outside your organization I can’t help but the repo access key will not work for you.
In the last couple of days, now that we use PAT instead of OAuth, all cloud builds of one of our project fails. Looking at the logs, it seems we don’t have access to a submodule anymore, we are getting an error 403.
I’ve tried switching the URL in the .gitmodules file to these 2 syntaxes, but both are still returning “Unable to access” errors.
A repository access token in BitBucket can only hit the repo that it has access to, so it won’t be able to pull down submodules. The way git works is that the submodule definition must match the same method used to fetch the repository. So if you configure UBA for PAT then https will be used by the git protocol (nothing we can do about it) to pull down the submodules.
If you are on standard BitBucket then I recommend using our GitSSH implementation for your project and setting your submodules to use SSH. If you have BitBucket premium then you can generate a project or workspace access token. When you use a workspace or project access token then the token can access any repo within the project/workspace it was created for.
I understand that this can be frustrating for our BitBucket users but hopefully the above provides some clarity.
You don’t have to provide write access unless you want to auto build. We create web hooks when the connection is setup so that we can build on code change. If you don’t want to auto build, or want to setup the hooks yourself you don’t have to provide write access. I believe our API documentation may have the information on the link that you would need to tell GitHub to hit in order to configure auto builds yourself.
Thanks for the extra details, Benjamin. Was able to get my builds working again with one of GitHub’s “fine-grained” PATs. For a token on one specific repo, I just granted read access to code and metadata, and read + write access for web hooks.
Hi. I have a private github repo added as a package in my project. I have setup PAT and added it in the Cloud Build dashboard. But I’m getting
[2023-12-31T16:21:28Z - Unity] Project has invalid dependencies:
[error] [2023-12-31T16:21:28Z - Unity] com.: Error when executing git command. remote: Write access to repository not granted.
[error] [2023-12-31T16:21:28Z - Unity] fatal: unable to access ‘https://github.com/’: The requested URL returned error: 403
I also experienced repo updates not triggering builds despite the auto-builds setting being enabled. The fine-grained PAT had only read permission for contents. I just created a new PAT with additional read/write permissions for Webhooks and now auto-builds are working.
As a Unity freelance developer, I am given outside contributor access to my client’s repos in Github. When I setup a PAT in Github to support Unity cloud build (all flags checked in the repo section) I am only able to see my own personal repos and not those where I have been granted access. How do I configure this so I can do Cloud builds of my client’s projects?
I’ve created PAT’s in GitHub, updated UCB with the tokens, re-authorised (and am now only seeing the relevant repo’s in the dropdown) but in the build logs it’s still referring to OAuth…
INFO: OAUTH: Checkout project…
INFO: GIT: git version (2.38.1)
INFO: OAUTH: Checking out…
INFO: GIT: Checking out via URI…
INFO: Attempt 1 of 5 to clone repository.
INFO: Cloned in 173 seconds.
INFO: OAUTH: Checkout operation complete.
Is this an issue or just UCB logging using OAUTH as a generic term for authentication?
Tbh I’m not even sure how it’s working with OAuth as my repo’s no longer seem to have SSH keys associated with them. Well none that I can see.
well… so much for the simplified and improved changes to login process… it’s been almost a month and not even an aknowledge from the team for the login issue. thanks a lot, guys.
i’m not using any triggers to make the build. i manually press Build and it fails. it doesn’t have access to repos that are not mine (but linked in the package manager)
Ah, gotcha, sorry I missed that detail in your earlier post. Might be a pain depending on how many packages we’re talking about, but as a workaround you might be able to clone the repos in question as local packages to dodge the need for giving Unity direct access.
Of course, ideally there’s a solution via the PAT credentials, but this might at least let you move past the issue for now.
I’m getting an error in cloud build that I wasn’t getting last week, using a personal access token from bitbucket I’m seeing
ERROR: OAUTH: Error during checkout: bad URI(is not URI?): numbers:numbersAndLetters/my-branch
Is there something currently broken with cloud build’s auth? The cloud build triggered from my branch so it’s able to see the webhook, and the PAT has read access to my repositories.
Is anyone else seeing this error?
Thanks
Thanks for pointing out that we reference oauth in the build process. It can for sure be confusing and we will need to update that. We did not change the log naming or any of our data models when we switched from OAuth to PAT. For example if you make an API call to get your project details you’ll see that the scm type is OAuth. The behavior of an OAuth token and PAT are identical in terms of how we interact with Git providers (outside of refresh tokens). I’ll try to update the log naming to help avoid confusion and get that out in our next release.
In our next release we are updating the repos that will be displayed in the source control configuration page to include all repos the token is an admin, collaborator or member of. This should make it easier so that the repo owner doesn’t have to be the one generating the token.
In terms of the BitBucket error we did not have a release this week so it sounds like this may be something else but you can open up a support ticket and one of our support engineers will try and take a look.
