Do not check SSO session for Git operations originating from CI/CD jobs

What does this MR do and why?

For #339888 (closed)

The problem

• The description of #339888 (closed) says that scheduled pipelines cannot run successfully because the owner of the pipeline schedule need not necessarily have a valid SSO session at the time the pipeline runs.
• The comment at #339888 (comment 678778770) adds a different scenario: A user that is close to their 24 hour session expiry, executes an action (say a git push), that executes a pipeline. This pipeline's git actions could run right after the 24 hour expiry and hence the pipeline fails because there is no valid SSO session by then.

The solution

Looking at these 2 points, my understanding of how to solve this problem is: We should be limiting SSO session check to only the user present git actions (think, a git push origin main executed from the user's terminal) and we should not be doing SSO session checks on actions that are done by GitLab on the user's behalf (think scheduled pipelines, pipelines triggered due to the user's action etc). Since the latter are actions done by the machine, there is always a chance that these actions occur outside the 24 hour window, and we cannot possibly expect that these actions will be able to find a valid SSO session.

Checking the code, I found that we already have a helper method named request_from_ci_build? that tells us if the git request originated from a CI build or not. Using this helper we can easily differentiate between git actions that originated via user present actions (like the git push origin main executed from the user's terminal) and the actions originating from CI. And for the actions originating from the CI, we can decide to skip the SSO check if request_from_ci_build? is true, thus solving our problem.

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

I actually hard a hard time setting up GitLab Runner in my local machine, I tried for 2 days, but I could not quite get it to work.

Then I realized that since the change is only a one-liner, I could easily test this out in a nightly build, so I did that.

Steps:

• Installed a nightly build on a digital ocean droplet.

• Setup a project in a group with a valid .gitlab-ci.yml.

• To test our specific use case, we can assume that an SSO session for the user does not exist. For this, we can make the method access_restricted? always return true. I edited the file to make this method always return true.

• Restart GitLab using sudo gitlab-ctl restart

• Next, we can run test cases via running the pipelines (both scheduled and unscheduled)

  In the current scenario, ie, in the case where

  • No SSO session exists (because we made access_restricted? always return true) and we have not allowed CI jobs to bypass SSO session checks (this is the current bug)

    • Normal git operation from the user: fails with "Cannot find valid SSO session" error
    • Git operations from a normal pipeline job: fails with "Cannot find valid SSO session" error
    • Git operations from scheduled pipeline job: fails with "Cannot find valid SSO session" error

• To allow CI jobs to bypass SSO session checks, we make this change in the GitLab installation by editing the file, restarting GitLab and trying out our test cases again.

  After the change, ie, in the case where

  • No SSO session exists (because we made access_restricted? always return true) and we have allowed CI jobs to bypass SSO session checks

    • Normal git operation from the user: fails with "Cannot find valid SSO session" error
    • Git operations from a normal pipeline job: completes successfully.
    • Git operations from scheduled pipeline job: completes successfully.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.