Added support to install gems from private repositories.

[nikhil2611]

This pull request updates CI workflows to improve support for private repositories and private Ruby gems, as well as to test a custom SBOM workflow branch. The most important changes are grouped below.

Private repository and gem access:

• Added a step to configure git with a GitHub access token for private repository access in the Ruby CLI build job of .github/workflows/ci-main-pull-request.yml.
• Added a similar git configuration step for private Ruby gems in .github/workflows/sbom.yml, ensuring that bundle install can access private gem sources.

SBOM workflow update:

• Updated the SBOM generation job in .github/workflows/ci-main-pull-request.yml to use a custom branch (nikhil/pull-private-gems-github-branch) of the shared SBOM workflow, likely for testing or to support private gem access.

Description

Related Issue

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

• I have read the CONTRIBUTING document.
• I have run the pre-merge tests locally and they pass.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• If Gemfile.lock has changed, I have used --conservative to do it and included the full output in the Description above.
• All new and existing tests passed.
• All commits have been signed-off for the Developer Certificate of Origin.

[sean-sype-simmons]

need to confirm that using the format x-access-token wont expose the token in the verbose output or when the job runs with debug.
using the git config global affects all git operations for that run on the node

this could lead to the cloning of a private repo
need to check on the scoping of the GH_PRIVATE_REPO_TOKEN i dont think that has any scopes limiting it.

I think we should investigate on using something like a PAT token for a specific repo, that only allows read, and or configure bundler in the run with something specific like: `

    bundle config set --local github.com "x-access-token:${{ secrets.GH_PRIVATE_REPO_TOKEN }}"

Which will set that at runtime during the bundle install.

Or we need to figure out a safer way to ship the private repos rubygem to a something thats accessible.

[nikhil2611]

need to confirm that using the format x-access-token wont expose the token in the verbose output or when the job runs with debug. using the git config global affects all git operations for that run on the node

this could lead to the cloning of a private repo need to check on the scoping of the GH_PRIVATE_REPO_TOKEN i dont think that has any scopes limiting it.

I think we should investigate on using something like a PAT token for a specific repo, that only allows read, and or configure bundler in the run with something specific like: `

    bundle config set --local github.com "x-access-token:${{ secrets.GH_PRIVATE_REPO_TOKEN }}"

Which will set that at runtime during the bundle install.

Or we need to figure out a safer way to ship the private repos rubygem to a something thats accessible.

@sean-sype-simmons Yeah right that using git config --global was too broad. It could affect all git operations in the job and increase the risk of unintended private repo access, especially depending on the token scope.
I’ve updated the workflow to use -
bundle config set --local github.com "x-access-token:${{ secrets.GH_PRIVATE_REPO_TOKEN }}"
This scopes the credentials only to Bundler, without modifying global git configuration. The token remains masked and it’s only used during bundle install.

[sean-sype-simmons]

need to confirm that using the format x-access-token wont expose the token in the verbose output or when the job runs with debug. using the git config global affects all git operations for that run on the node
this could lead to the cloning of a private repo need to check on the scoping of the GH_PRIVATE_REPO_TOKEN i dont think that has any scopes limiting it.
I think we should investigate on using something like a PAT token for a specific repo, that only allows read, and or configure bundler in the run with something specific like: `
    bundle config set --local github.com "x-access-token:${{ secrets.GH_PRIVATE_REPO_TOKEN }}"
Which will set that at runtime during the bundle install.
Or we need to figure out a safer way to ship the private repos rubygem to a something thats accessible.

@sean-sype-simmons Yeah right that using git config --global was too broad. It could affect all git operations in the job and increase the risk of unintended private repo access, especially depending on the token scope. I’ve updated the workflow to use - bundle config set --local github.com "x-access-token:${{ secrets.GH_PRIVATE_REPO_TOKEN }}" This scopes the credentials only to Bundler, without modifying global git configuration. The token remains masked and it’s only used during bundle install.

Thanks for that. We need to have a larger discussion on this. I believe these settings may be better in your own repo with an override setting. However, we dont want to be managing multiple PAT's. There has to be a better way forward on this.