Git

use the git integration to connect resolve ai to your codebase — to query code during investigations, pull relevant evidence, and propose code changes for you to review resolve's git integration is designed to fit how your organization is set up it supports both a cloud only and a hybrid (satellite based) architecture, and multiple authentication methods, so a single integration can cover github com, github enterprise (cloud or server), gitlab, bitbucket, azure devops, and self hosted git how resolve connects to your codebase through git connecting resolve ai to your code comes down to two independent choices where git commands run git on cloud (resolve managed) or git on satellite (your kubernetes / ecs) how resolve authenticates github (resolve ai's app for github), ghe (bring your own github app), or token (pat) all three work on both cloud and satellite 1\ choosing an execution plane cloud or satellite your first decision is where resolve actually clones, fetches, and queries your repositories the right choice depends on your network reachability, your data residency requirements, and how much infrastructure your team is prepared to operate area git on cloud git on satellite where git commands run resolve managed cloud infrastructure a satellite worker you deploy in your environment who operates infrastructure resolve your team repository reachability reachable from resolve cloud reachable from your satellite, including private networks and air gapped instances storage location resolve managed persistent storage a volume on your satellite (pvc for kubernetes, efs for ecs) the resolve satellite is supported on kubernetes and on aws ecs fargate the kubernetes deployment stores repositories on a gitvolume (pvc is recommended for production); the ecs deployment uses an efs volume both are functionally identical, so the choice comes down to whichever infrastructure your team already operates once you've decided, follow the matching setup guide set up git on cloud docid\ wc n203zyy6b3qi3xogwc for resolve managed execution set up git on satellite (kubernetes) docid\ afbmngox7mekvqjyawf6t for in cluster execution set up satellite on ecs docid\ fc4sborfgfm4gyerrtjpt for aws fargate execution 2\ choosing an authentication method after picking an execution plane, decide how resolve proves identity to your git host all three auth types work on both cloud and satellite — the choice is driven by which git host your code lives on , your security policy , and how you want to manage the git app github — connects to github com through resolve ai's app for github you complete an oauth style installation, and resolve handles token rotation automatically ghe — connects through a custom github app that you own, on any github variant (github com, github enterprise cloud, or github enterprise server) you provide the app id, installation id, and private key, and resolve calls the api base url you configure token — connects to non github providers (gitlab, bitbucket, azure devops, self hosted git) or to github via pat resolve authenticates with the username and personal access token you provide one integration can use all three auth types a single git integration can carry multiple auth configs side by side under authconfigs — for example, one github config for github com repos, one ghe config for an on prem ghe instance, and one or more token configs for gitlab or bitbucket each is keyed independently and matched to its credentials match your setup to an auth type your setup pick why standard github com, no policy on which github app you use github one click install of resolve ai's app for github — no app credentials, no private key, no base url fastest path github com, but compliance / audit / scoped permissions require a customer owned app ghe you operate the app, control the permission set, and rotate keys on your schedule works against https //api github com github enterprise cloud ( ghe com ) ghe resolve ai's app for github is github com only; ghe cloud requires your own app on your tenant github enterprise server (on prem), reachable from resolve cloud ghe on cloud your own app on your ghe server, with baseurl pointing at /api/v3 github enterprise server (on prem), only reachable from inside your network ghe on satellite code never leaves your network the satellite reaches ghe server directly gitlab, bitbucket, azure devops, self hosted git, or github via pat token app based auth doesn't apply for non github providers for github via pat, use this when an app install is impossible (locked down org, individual account repos) mixed providers (e g github com + on prem ghe + gitlab) multiple auth configs in one integration github + ghe + token can coexist under authconfigs once you've decided, follow the matching walkthrough connect via resolve ai's app for github docid 3qpkzkw5e48k9fnlwkp7 for github auth on github com bring your own github app docid 3qpkzkw5e48k9fnlwkp7 for ghe auth (github com, ghe cloud, or ghe server) for token auth, first create the pat docid\ p5hisb3e bt8dhqjgu353 , then complete the connection under option 3 in the cloud docid\ wc n203zyy6b3qi3xogwc or satellite docid\ afbmngox7mekvqjyawf6t guide what resolve can do once connected reads vs writes these behaviors apply to both cloud and satellite reads are always enabled cloning, fetching, searching, reading files, viewing history, generating diffs, and inspecting blame data write/remediation tools (proposing code changes, opening prs) are controlled by disablewrites with a github or ghe auth config, writes are enabled by default with token only auth, writes are disabled by default set disablewrites explicitly in your connection config to override either default for the full schema ( authconfigs , tokenauthcredentials , gheauthcredentials , disabledsubcommands , certificate overrides), see the git on cloud docid\ wc n203zyy6b3qi3xogwc or git on satellite docid\ afbmngox7mekvqjyawf6t setup guide creating access tokens when you use token auth, you provide a username and personal access token (pat) that resolve uses to authenticate to your git host the steps below apply to every execution plane create the token here, then follow your setup guide ( cloud docid\ wc n203zyy6b3qi3xogwc , satellite docid\ afbmngox7mekvqjyawf6t , or ecs docid\ fc4sborfgfm4gyerrtjpt ) for where to store it every token can be created in one of two flavours, regardless of provider write (remediation), recommended resolve investigates and also proposes fixes, pushing a branch and opening a pull/merge request for your review requires write scopes on the token and disablewrites false on the connection read only (restricted) resolve clones code and reads commits, branches, pull/merge requests, pipelines/ci, and metadata, but cannot open prs/mrs this is the technical default for token only auth ( disablewrites true ) choose it only if your policy requires investigate only access pick the flavour that matches how you want to use resolve github github supports fine grained and classic pats fine grained token (recommended) go to settings > developer settings > personal access tokens > fine grained tokens click generate new token and set a name and expiration choose the resource owner and select the repositories to grant access to set repository permissions read and write on contents (code) and pull requests these two enable pull request creation set them to read only if you only need investigation reads read only on metadata (mandatory), actions , checks , commit statuses , deployments , discussions , issues , and merge queues if your org uses sso, authorize the token for sso after creation generate and copy the token classic token go to settings > developer settings > personal access tokens > tokens (classic) generate a token and set an expiration select scopes private repositories repo public only workflows public repo authorize sso for your org if required copy the token classic pats with repo scope are broad prefer fine grained pats when possible gitlab gitlab access is gated by two independent controls, and you must satisfy both token scopes the checkboxes you select when creating the pat membership role the role (guest, reporter, developer, and so on) the token's owner has on the projects or groups you connect a token's effective access is the intersection of its scopes and the owner's role an api scoped token owned by a reporter still cannot push or open merge requests pick the flavour that matches what you want resolve to do merge request creation (write, recommended) lets resolve investigate and open merge requests for your review includes every read capability, plus branch push and mr creation go to preferences > access tokens (or use a project/group access token) create a token with an expiration select scope api the only read write api scope it covers mr creation and also includes git over https clone/fetch/push, so it subsumes read repository / write repository write repository is not sufficient on its own it only enables git push over https and does not support api authentication, so it cannot create a merge request ensure the owner has at least the developer role on the connected projects/groups developer is the minimum role that can push branches and create merge requests copy the token set disablewrites false on the connection to allow write/remediation tools read only (restricted) lets resolve clone code and read commits, branches, merge requests, pipelines, ci job logs, and project metadata, but not open merge requests choose this only if your policy requires investigate only access go to preferences > access tokens (for a personal token), or use a project/group access token https //docs gitlab com/user/project/settings/project access tokens/ to scope it to specific repos create a token with an expiration select scopes read repository clone/fetch code over https read api read merge requests, pipelines, jobs, commits, and metadata via the gitlab api both are required read repository alone does not grant api reads of mrs/pipelines, and read api alone does not grant git over https clone ensure the owner has at least the reporter role on the connected projects/groups on private projects, guest cannot read code, so reporter is the minimum copy the token keep disablewrites true (the default for token only auth) for this flavour classic gitlab pats are not per repository like github fine grained tokens they can access every project the owning user can to limit blast radius, use a project or group access token https //docs gitlab com/user/project/settings/project access tokens/ (assign it the reporter or developer role per the flavour above) or a fine grained personal access token https //docs gitlab com/auth/tokens/fine grained access tokens/ instead of a classic pat other providers (bitbucket, azure devops, self hosted) token auth works with any provider that supports https pats the principle is the same as above grant the minimum the flavour needs read only scopes that allow repository read/clone plus reading pull requests and pipelines/builds (e g bitbucket repositories read + pull requests read + pipelines read ; azure devops code (read) + build (read) ) write (remediation) add the provider's repository write and pull request write scopes so resolve can push branches and open prs if your host uses a custom or self signed certificate, see the certificate override options in the satellite setup guide docid\ afbmngox7mekvqjyawf6t get started you want… start here fastest onboarding, no infra work set up git on cloud docid\ wc n203zyy6b3qi3xogwc in cluster execution on kubernetes set up git on satellite docid\ afbmngox7mekvqjyawf6t aws native execution without kubernetes set up satellite on ecs docid\ fc4sborfgfm4gyerrtjpt resolve ai's app for github walkthrough app for github → resolve ai's app docid 3qpkzkw5e48k9fnlwkp7 bring your own github app walkthrough app for github → byo github app docid 3qpkzkw5e48k9fnlwkp7