Backend: Predefined variable CI_COMMIT_REF_PROTECTED wrong value for merge request
Summary
I would like to disable merge request pipeline when merge from protected branches e.g. from develop branch to staging branch. I use feature flag strategy so do not need this.
The problem is that CI_COMMIT_REF_PROTECTED
has the wrong value (false).
Steps to reproduce
- Create new repo
- Add two branches e.g. main, staging
- Mark both branches as protected
- Add simple
.gitlab-ci.yml
like:
repro:
script:
- env | grep 'CI_COMMIT_REF_PROTECTED\|CI_COMMIT_REF_NAME\|CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED\|CI_MERGE_REQUEST_TARGET_BRANCH_NAME'
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
- if: '$CI_PIPELINE_SOURCE != "merge_request_event"'
- Create merge request staging -> main
- Check logs for merge request pipeline:
CI_COMMIT_REF_PROTECTED
will be false
Reproduced on GitLab.com: https://gitlab.com/gl-demo-ultimate-mgrabowski/mg-gold/zd-373435 See Add README.md (gl-demo-ultimate-mgrabowski/mg-gold/zd-373435!4) and compare output of branch pipeline vs. merge request pipeline.
User Impact
Users wishing to use CI_COMMIT_REF_PROTECTED
are unable to as it returns the wrong value.
Proposal
- Modify
pipeline#protected_ref?
to render the correct value
def protected_ref?
- strong_memoize(:protected_ref) { project.protected_for?(git_ref) }
+ strong_memoize(:protected_ref) { project.protected_for?(source_ref_path) }
end
Designs
- Show closed items
Relates to
Activity
-
Newest first Oldest first
-
Show all activity Show comments only Show history only
- 🤖 GitLab Bot 🤖 added automation:ml grouppipeline authoring labels
added automation:ml grouppipeline authoring labels
- Maintainer
This issue was automatically tagged with the label grouppipeline authoring by TanukiStan, a machine learning classification model, with a probability of 1.
If this label is incorrect, please tag this issue with the correct group label as well as automation:ml wrong to help TanukiStan learn from its mistakes.
This message was generated automatically. You're welcome to improve it.
- Maintainer
Setting label(s) devopsverify sectionops based on grouppipeline authoring.
- 🤖 GitLab Bot 🤖 added devopsverify sectionops labels
added devopsverify sectionops labels
- 🤖 GitLab Bot 🤖 mentioned in issue gitlab-org/quality/triage-reports#7758 (closed)
mentioned in issue gitlab-org/quality/triage-reports#7758 (closed)
- Dov Hershkovitch added typebug + 1 deleted label
added typebug + 1 deleted label
- Dov Hershkovitch changed milestone to %Backlog
changed milestone to %Backlog
- Mark Nuzzo added severity2 label
added severity2 label
- 🤖 GitLab Bot 🤖 added [deprecated] Accepting merge requests label
added [deprecated] Accepting merge requests label
- 🤖 GitLab Bot 🤖 added priority2 label
added priority2 label
- Maintainer
@marknuzzo and @dhershkovitch,This grouppipeline authoring bug has at most 25% of the SLO duration remaining and is ~"approaching-SLO" breach. Please consider taking action before this becomes a ~"missed-SLO" in 14 days (2022-07-30).
Collapse replies - Contributor
Posted comment in https://gitlab.slack.com/archives/C03KWUPMXLM/p1658368986526699 to determine next steps, if any, on priority here.
- 🤖 GitLab Bot 🤖 added SLONear Miss label
added SLONear Miss label
- 🤖 GitLab Bot 🤖 added SLOMissed label
added SLOMissed label
- Mark Nuzzo added CI variables backend labels
added CI variables backend labels
- Mark Nuzzo changed title from Predefined variable CI_COMMIT_REF_PROTECTED wrong value for merge request to Backend: Predefined variable CI_COMMIT_REF_PROTECTED wrong value for merge request
changed title from Predefined variable CI_COMMIT_REF_PROTECTED wrong value for merge request to Backend: Predefined variable CI_COMMIT_REF_PROTECTED wrong value for merge request
- Mark Nuzzo changed the description
Compare with previous version changed the description
Premium customer here encountered this issue. On an MR pipeline where both the source and target branches are protected, the environment variables set by GitLab incorrectly give us:
CI_COMMIT_REF_NAME=develop CI_COMMIT_REF_PROTECTED=false
There is also this variable available:
CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED=true
But there is no
CI_MERGE_REQUEST_SOURCE_BRANCH_PROTECTED
variable available.Edited by Robert RossCollapse replies - Contributor
FYI: contributed this change some time ago: Expose source branch protected and squash CI vars (!127848 - merged)
Note that is also means it breaches protected vs. unprotected
cache
since it considers the source branch of this MR (develop
) to be "non-protected" due to the bug:Uploading cache.zip to https://our-cache.s3.whatever.amazonaws.com/runner/project/9999/npm-cache-data-develop-non_protected
Edited by Robert Ross@marknuzzo - Premium customer experiencing a lot of frustration here which is impeding their progress migrating from Jenkins.
Are there any updates I can share on priority or timeline? Thanks!
1Collapse replies - Contributor
Hi @jcaggiano - thanks for reaching out here. I'm going to pull in our PM (@dhershkovitch) so he can provide thoughts around priority and hopefully, we can help move this forward soon.
- Developer
@marknuzzo I've marked it as candidate15.9, let's weight it first so we can understand the effort
1 1 - Maintainer
@marknuzzo @dhershkovitch I was not able to reproduce this.
I tried three different ways.
I assumed this is what the user meant when they said
main -> staging
, although they got afalse
so I'm not sure this assumption is correct.-
A protected branch
main
targetingnon-protected-branch
:CI_COMMIT_REF_PROTECTED=true
<- This is correct
Example job: https://gitlab.com/lauraX/demo-project/-/jobs/3735360106
Example MR: https://gitlab.com/lauraX/demo-project/-/merge_requests/3 -
From a
non-protected-branch
branch targeting a protected branchmain
:CI_COMMIT_REF_PROTECTED=false
<- This is correct
Example job: https://gitlab.com/lauraX/demo-project/-/jobs/3735279529
Example MR: https://gitlab.com/lauraX/demo-project/-/merge_requests/2 -
A protected branch targeting protected branch:
CI_COMMIT_REF_PROTECTED=true
<- This is correct
Example MR: https://gitlab.com/lauraX/demo-project/-/merge_requests/1
Example job: https://gitlab.com/lauraX/demo-project/-/jobs/3735259268
You can see the variables and ref names in the jobs and they all correspond to non-protected and protected as well. Perhaps @robert.ross (latest) can provide a sample of the customer's config, since with the config provided this is not a bug.
Edited by Laura Montemayor -
- 🤖 GitLab Bot 🤖 added customer label
added customer label
- Dov Hershkovitch added candidate15.9 workflowplanning breakdown labels
added candidate15.9 workflowplanning breakdown labels
- Mark Nuzzo added candidate15.10 label and removed candidate15.9 label
added candidate15.10 label and removed candidate15.9 label
- Laura Montemayor assigned to @lauraX
assigned to @lauraX
Perhaps this might be related to the specifics of how branch protection rules are set up or the runner being used? What I cannot see in your example links @lauraX is the branch protection rules associated with this testing. For example, we have these rules right now in our tests:
Our pipeline configuration is too complex to send in its entirety. I can say for certain that we were absolutely seeing the problem on our builds from
develop
tomaster
in GitLab15.7.5
with a15.6.1
runner and the Kubernetes executor. We have since updated to15.8.1
but I haven't yet found a build of this flavor to see if this is still occuring.I see your tests are using
15.9.0-pre
and15.9.0~beta.84.gdf5ed1cb
runner and the Docker executor. Attempting to reproduce this with a pre-release that customers are most likely not using seems a bit odd to me and somewhat negates the effort. If this was fixed already by accident, it would still be good to know how and why. If there are differences between configuration or a corner case involved, your using pre-release software complicates our ability to close that gap.Edited by Robert RossCollapse replies - Maintainer
The only protected branches are
main
andprotected-branch
:I am not sure when this was fixed because I have been unable to reproduce this based on the user's description above.
If you feel like this is still a bug, please feel free to add steps reproduce so it can be triaged accordingly. @marknuzzo I am un-assigning myself from this since this as it stands isn't a bug.
1 1 Perhaps at least try adding "main*" as another protected branch matcher and see if wildcards are the corner case? I can't speak for the original author of this ticket, but clearly more than one user (paying customer here) is experiencing this problem. Dismissing it as "not a bug" with such a limited test on a pre-release/beta version after just asking said customer to provide more info (at my expense) on a different released version is premature and bad customer service. You appear to have given the issue less than 24 hours of consideration before dismissing it.
Edited by Robert Ross- Developer
@robert.ross I want to assure you that this issue is not overlooked, since we iterate, we have a standard process on how to schedule issue to a certain milestone, the discussion is still undergoing and the issue will get triaged
Thank you. I very much appreciate @manuelgrabowski taking on the effort of reproducing this issue.
If it helps, here is the latest log output (scrubbed) from one of our jobs.
[0KRunning with gitlab-runner 15.6.1 (133d7e76)[0;m [0K on gitlab-runner-6fc48bc849-vr4vh o57URn61[0;m section_start:1674141368:resolve_secrets [0K[0K[36;1mResolving secrets[0;m[0;m section_end:1674141368:resolve_secrets [0Ksection_start:1674141368:prepare_executor [0K[0K[36;1mPreparing the "kubernetes" executor[0;m[0;m [0KUsing Kubernetes namespace: gitlab-build-runner-1[0;m [0KUsing Kubernetes executor with image git.ourcompany.com:443/nl/dependency_proxy/containers/node:14-slim ...[0;m [0KUsing attach strategy to execute scripts...[0;m section_end:1674141368:prepare_executor [0Ksection_start:1674141368:prepare_script [0K[0K[36;1mPreparing environment[0;m[0;m Waiting for pod gitlab-build-runner-1/runner-o57urn61-project-140-concurrent-0gv44w to be running, status is Pending Waiting for pod gitlab-build-runner-1/runner-o57urn61-project-140-concurrent-0gv44w to be running, status is Pending ContainersNotReady: "containers with unready status: [build helper]" ContainersNotReady: "containers with unready status: [build helper]" Running on runner-o57urn61-project-140-concurrent-0gv44w via gitlab-runner-6fc48bc849-vr4vh... section_end:1674141375:prepare_script [0Ksection_start:1674141375:get_sources [0K[0K[36;1mGetting source from Git repository[0;m[0;m [32;1mFetching changes with git depth set to 20...[0;m Initialized empty Git repository in /builds/nl/node-ourcompany-utils/.git/ [32;1mCreated fresh repository.[0;m [32;1mChecking out 00d8aa19 as refs/merge-requests/51/head...[0;m [32;1mSkipping Git submodules setup[0;m section_end:1674141376:get_sources [0Ksection_start:1674141376:restore_cache [0K[0K[36;1mRestoring cache[0;m[0;m [32;1mChecking cache for npm-cache-data-develop-non_protected...[0;m [0;33mWARNING: file does not exist [0;m [0;33mFailed to extract cache[0;m section_end:1674141376:restore_cache [0Ksection_start:1674141376:step_script [0K[0K[36;1mExecuting "step_script" stage of the job script[0;m[0;m [32;1m$ npm config set $ARTIFACT_NPM_SCOPE:registry $ARTIFACT_REPO_NPM_URL_SCHEME://$ARTIFACT_REPO_NPM_URL[0;m [32;1m$ npm config set -- //$ARTIFACT_REPO_NPM_URL:_authToken $ARTIFACT_REPO_NPM_TOKEN[0;m [32;1m$ # Installing any potentially missing script dependencies... # collapsed multi-line command[0;m debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package libpcre2-8-0:amd64. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 6469 files and directories currently installed.) Preparing to unpack .../0-libpcre2-8-0_10.32-5_amd64.deb ... Unpacking libpcre2-8-0:amd64 (10.32-5) ... Selecting previously unselected package libpsl5:amd64. Preparing to unpack .../1-libpsl5_0.20.2-2_amd64.deb ... Unpacking libpsl5:amd64 (0.20.2-2) ... Selecting previously unselected package wget. Preparing to unpack .../2-wget_1.20.1-1.1_amd64.deb ... Unpacking wget (1.20.1-1.1) ... Selecting previously unselected package libssl1.1:amd64. Preparing to unpack .../3-libssl1.1_1.1.1n-0+deb10u3_amd64.deb ... Unpacking libssl1.1:amd64 (1.1.1n-0+deb10u3) ... Selecting previously unselected package openssl. Preparing to unpack .../4-openssl_1.1.1n-0+deb10u3_amd64.deb ... Unpacking openssl (1.1.1n-0+deb10u3) ... Selecting previously unselected package ca-certificates. Preparing to unpack .../5-ca-certificates_20200601~deb10u2_all.deb ... Unpacking ca-certificates (20200601~deb10u2) ... Selecting previously unselected package publicsuffix. Preparing to unpack .../6-publicsuffix_20220811.1734-0+deb10u1_all.deb ... Unpacking publicsuffix (20220811.1734-0+deb10u1) ... Setting up libpsl5:amd64 (0.20.2-2) ... Setting up libssl1.1:amd64 (1.1.1n-0+deb10u3) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline debconf: unable to initialize frontend: Readline debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) debconf: falling back to frontend: Teletype Setting up libpcre2-8-0:amd64 (10.32-5) ... Setting up openssl (1.1.1n-0+deb10u3) ... Setting up publicsuffix (20220811.1734-0+deb10u1) ... Setting up wget (1.20.1-1.1) ... Setting up ca-certificates (20200601~deb10u2) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline debconf: unable to initialize frontend: Readline debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) debconf: falling back to frontend: Teletype Updating certificates in /etc/ssl/certs... 137 added, 0 removed; done. Processing triggers for libc-bin (2.28-10+deb10u2) ... Processing triggers for ca-certificates (20200601~deb10u2) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. [32;1m$ wget -q -O /usr/local/bin/semver https://raw.githubusercontent.com/fsaintjacques/semver-tool/master/src/semver[0;m [32;1m$ chmod +x /usr/local/bin/semver[0;m [32;1m$ # Declaring resolveSemver() function... # collapsed multi-line command[0;m [32;1m$ mkdir -p $CI_CODE_ANALYSIS_DIR[0;m [32;1m$ # Capturing environment and build data...[0;m [32;1m$ env >> $CI_CODE_ANALYSIS_DIR/environment.log[0;m [32;1m$ CI_PACKAGE_NAME=$(node -p "require('./package.json').name")[0;m [32;1m$ CI_PACKAGE_VERSION=$(node -p "require('./package.json').version")[0;m [32;1m$ CI_IS_STAGING_BUILD=$(echo $CI_COMMIT_REF_NAME | sed -nE "${REGEX_STAGING_BRANCH}p" | wc -l)[0;m [32;1m$ CI_IS_RELEASE_BUILD=$(echo $CI_COMMIT_REF_NAME | sed -nE "${REGEX_RELEASE_BRANCH}p" | wc -l)[0;m [32;1m$ if [ $CI_IS_STAGING_BUILD -eq 1 ] && [ $CI_IS_RELEASE_BUILD -eq 1 ]; then # collapsed multi-line command[0;m [32;1m$ CI_RESOLVED_RELEASE_VERSION=$(resolveSemver $CI_PACKAGE_VERSION release false)[0;m [DEBUG] 1="5.5.0-dev" 2="release" 3="false" [DEBUG] originalSemver="5.5.0-dev" releaseSemver="5.5.0" isStagingBuild=0 isReleaseBuild=1 isReleaseVersion=0 includeBuild=0 [DEBUG] Resolving version... [DEBUG] - Starting with release data... [32;1m$ if [ $CI_IS_STAGING_BUILD -eq 1 ]; then # collapsed multi-line command[0;m [DEBUG] 1="5.5.0-dev" 2="staging" 3="" [DEBUG] originalSemver="5.5.0-dev" releaseSemver="5.5.0" isStagingBuild=1 isReleaseBuild=0 isReleaseVersion=0 includeBuild=1 [DEBUG] Resolving version... [DEBUG] - Starting with release data... [DEBUG] - Including pre-release tag... [DEBUG] - Including build number... [32;1m$ echo CI_PACKAGE_NAME=$CI_PACKAGE_NAME >> npm.build.env[0;m [32;1m$ echo CI_PACKAGE_VERSION=$CI_PACKAGE_VERSION >> npm.build.env[0;m [32;1m$ echo CI_RESOLVED_VERSION=$CI_RESOLVED_VERSION >> npm.build.env[0;m [32;1m$ echo CI_RESOLVED_RELEASE_VERSION=$CI_RESOLVED_RELEASE_VERSION >> npm.build.env[0;m [32;1m$ echo CI_IS_STAGING_BUILD=$CI_IS_STAGING_BUILD >> npm.build.env[0;m [32;1m$ echo CI_IS_RELEASE_BUILD=$CI_IS_RELEASE_BUILD >> npm.build.env[0;m [32;1m$ cat npm.build.env >> $CI_CODE_ANALYSIS_DIR/environment.log[0;m [32;1m$ npx envinfo >> $CI_CODE_ANALYSIS_DIR/environment.log[0;m npx: installed 1 in 1.776s [32;1m$ npm config list >> $CI_CODE_ANALYSIS_DIR/environment.log[0;m [32;1m$ [ "$CI_DEBUG_PIPELINE" == "true" ] && >&2 cat $CI_CODE_ANALYSIS_DIR/environment.log || true[0;m KUBERNETES_SERVICE_PORT_HTTPS=443 CI_PROJECT_NAMESPACE=nl GITLAB_USER_ID=66 SAST_EXCLUDED_ANALYZERS= CI_RUNNER_VERSION=15.6.1 CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED=true SONAR_TO_OPENMETRIC_JQ=/builds/nl/node-ourcompany-utils.tmp/SONAR_TO_OPENMETRIC_JQ ARTIFACT_NPM_SCOPE=@ourcompany FF_SKIP_NOOP_BUILD_STAGES=true GITLAB_RUNNER_SERVICE_PORT=9252 KUBERNETES_SERVICE_PORT=443 npm_config_cache=/builds/nl/node-ourcompany-utils/.npm CI_SERVER_NAME=GitLab CI_RUNNER_DESCRIPTION=gitlab-runner-6fc48bc849-vr4vh GITLAB_USER_EMAIL=fred.johnson@ourcompany.com CI_SERVER_REVISION=677cf66582b FF_USE_WINDOWS_LEGACY_PROCESS_STRATEGY=true CI_MERGE_REQUEST_SOURCE_BRANCH_NAME=develop CI_MERGE_REQUEST_TARGET_BRANCH_SHA= CI_RUNNER_EXECUTABLE_ARCH=linux/amd64 CI_REGISTRY_USER=gitlab-ci-token CI_API_V4_URL=https://git.ourcompany.com/api/v4 CI_REGISTRY_PASSWORD=[MASKED] CI_RUNNER_SHORT_TOKEN=o57URn61 CI_JOB_NAME=Initialization CI_USER_NAME=Continuous Integration CI_OPEN_MERGE_REQUESTS=nl/node-ourcompany-utils!51 TEAMS_PUBLISH_ACTIVITY=1 HOSTNAME=runner-o57urn61-project-140-concurrent-0gv44w GITLAB_USER_LOGIN=fred.johnson CI_PROJECT_NAME=node-ourcompany-utils CI_PIPELINE_SOURCE=merge_request_event CI_BUILD_REF_NAME=develop CI_JOB_STATUS=running ARANGO_DOCKER_IMAGE=git.ourcompany.com:443/nl/dependency_proxy/containers/arangodb:3.8 CI_PIPELINE_ID=7803 FF_DISABLE_POWERSHELL_STDIN=false CI_BUILD_REF_SLUG=develop CI_COMMIT_REF_SLUG=develop CI_MERGE_REQUEST_SOURCE_PROJECT_PATH=nl/node-ourcompany-utils CI_SERVER=yes NODEJS_VERSION=14 CI_PIPELINE_TOKEN=[MASKED] YARN_VERSION=1.22.19 CI_COMMIT_SHORT_SHA=00d8aa19 CI_JOB_NAME_SLUG=initialization FF_CMD_DISABLE_DELAYED_ERROR_LEVEL_EXPANSION=false REGEX_BUILD_ARTIFACT_PIPELINE_LABEL=/((\bpipeline::sandbox\b)|(\bpipeline::image\b))/ CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX=git.ourcompany.com:443/nl/dependency_proxy/containers REGEX_RELEASE_BRANCH=/(master|main)([-\/].*)?/ GITLAB_RUNNER_PORT_9252_TCP_PROTO=tcp PWD=/builds/nl/node-ourcompany-utils CI_RUNNER_TAGS=[] CI_MERGE_REQUEST_DIFF_BASE_SHA=e2d182952103ce8af603e07e9749eec78770df35 CI_PROJECT_PATH=nl/node-ourcompany-utils CI_CODE_ANALYSIS_DIR=analysis CI_MERGE_REQUEST_SOURCE_PROJECT_URL=https://git.ourcompany.com/nl/node-ourcompany-utils FF_USE_NEW_BASH_EVAL_STRATEGY=false CI_SERVER_TLS_CA_FILE=/builds/nl/node-ourcompany-utils.tmp/CI_SERVER_TLS_CA_FILE CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX=git.ourcompany.com:443/nl/dependency_proxy/containers SAST_IMAGE_SUFFIX= CI_MERGE_REQUEST_PROJECT_URL=https://git.ourcompany.com/nl/node-ourcompany-utils SONAR_HOST_URL=https://sonarqube.ourcompany.com CI_MERGE_REQUEST_ASSIGNEES=fred.johnson SONAR_TO_CODECLIMATE_JQ=/builds/nl/node-ourcompany-utils.tmp/SONAR_TO_CODECLIMATE_JQ CI_COMMIT_REF_PROTECTED=false FF_USE_POWERSHELL_PATH_RESOLVER=false CI_MERGE_REQUEST_TITLE=Release 5.5.0 DEPENDENCY_CHECK_CONFIG=/builds/nl/node-ourcompany-utils.tmp/DEPENDENCY_CHECK_CONFIG CI_SERVER_VERSION_MINOR=7 ARTIFACT_REPO_NPM_URL=artifact.ourcompany.com/repository/npm-internal/ CI_COMMIT_SHA=00d8aa19a1f4fc98aff1dafffe13258782cf036e HOME=/root FF_NETWORK_PER_BUILD=false CI_DEPENDENCY_PROXY_PASSWORD=[MASKED] KUBERNETES_PORT_443_TCP=tcp://172.20.0.1:443 CI_PROJECT_VISIBILITY=internal CI_CONCURRENT_PROJECT_ID=0 FF_SCRIPT_SECTIONS=false CI_COMMIT_MESSAGE=Merge branch 'NCP-1041-export-enum-utils-properly' into 'develop' Resolve NCP-1041 "Export enum utils properly" Closes NCP-1041 See merge request nl/node-ourcompany-utils!50 SECURE_ANALYZERS_PREFIX=registry.gitlab.com/security-products CI_JOB_JWT_V1=[MASKED] CI_JOB_JWT_V2=[MASKED] CI_BUILD_NAME=Initialization FF_USE_DIRECT_DOWNLOAD=true CI_PAGES_DOMAIN=example.com CI_SERVER_VERSION=15.7.5-ee CI_MERGE_REQUEST_PROJECT_PATH=nl/node-ourcompany-utils CI_REGISTRY=git.ourcompany.com:5050 CI_SERVER_PORT=443 CI_MERGE_REQUEST_IID=51 CI_PROJECT_NAMESPACE_ID=147 ARTIFACT_REPO_NPM_TOKEN=[MASKED] FF_USE_IMPROVED_URL_MASKING=false CI_MERGE_REQUEST_PROJECT_ID=140 GITLAB_RUNNER_PORT=tcp://172.20.35.63:9252 CI_MERGE_REQUEST_ID=16163 CI_PAGES_URL=http://nl.example.com/node-ourcompany-utils SEMVER_PRERELEASE_TAG=dev CI_PIPELINE_IID=87 CI_REPOSITORY_URL=https://gitlab-ci-token:[MASKED]@git.ourcompany.com/nl/node-ourcompany-utils.git CI_SERVER_URL=https://git.ourcompany.com FF_ENABLE_BASH_EXIT_CODE_CHECK=false GITLAB_FEATURES=audit_events,blocked_issues,board_iteration_lists,code_owners,code_review_analytics,contribution_analytics,description_diffs,elastic_search,full_codequality_report,group_activity_analytics,group_bulk_edit,group_webhooks,issuable_default_templates,issue_weights,iterations,ldap_group_sync,member_lock,merge_request_approvers,milestone_charts,multiple_issue_assignees,multiple_ldap_servers,multiple_merge_request_assignees,multiple_merge_request_reviewers,project_merge_request_analytics,protected_refs_for_users,push_rules,repository_mirrors,resource_access_token,seat_link,scoped_issue_board,usage_quotas,visual_review_app,wip_limits,send_emails_from_admin_area,repository_size_limit,adjourned_deletion_for_projects_and_groups,admin_audit_log,auditor_user,blocking_merge_requests,board_assignee_lists,board_milestone_lists,ci_cd_projects,ci_secrets_management,cluster_agents_ci_impersonation,cluster_deployments,code_owner_approval_required,commit_committer_check,commit_committer_name_check,compliance_framework,custom_compliance_frameworks,cross_project_pipelines,custom_file_templates,custom_file_templates_for_namespace,custom_project_templates,cycle_analytics_for_groups,cycle_analytics_for_projects,db_load_balancing,default_branch_protection_restriction_in_groups,default_project_deletion_protection,disable_name_update_for_users,disable_personal_access_tokens,domain_verification,email_additional_text,epics,extended_audit_events,external_authorization_service_api_management,feature_flags_related_issues,feature_flags_code_references,file_locks,geo,generic_alert_fingerprinting,git_two_factor_enforcement,github_integration,group_allowed_email_domains,group_coverage_reports,group_forking_protection,group_merge_request_analytics,group_milestone_project_releases,group_project_templates,group_repository_analytics,group_saml,group_scoped_ci_variables,group_wikis,incident_sla,incident_metric_upload,ide_schema_config,issues_analytics,jira_issues_integration,ldap_group_sync_filter,merge_pipelines,merge_request_performance_metrics,admin_merge_request_approvers_rules,merge_trains,metrics_reports,multiple_alert_http_integrations,multiple_approval_rules,multiple_group_issue_boards,object_storage,operations_dashboard,package_forwarding,pages_size_limit,password_complexity,productivity_analytics,project_aliases,protected_environments,reject_non_dco_commits,reject_unsigned_commits,saml_group_sync,scoped_labels,smartcard_auth,swimlanes,type_of_work_analytics,minimal_access_role,unprotection_restrictions,ci_project_subscriptions,incident_timeline_view,oncall_schedules,escalation_policies,export_user_permissions,zentao_issues_integration,coverage_check_approval_rule,issuable_resource_links,group_protected_branches,group_ip_restriction GITLAB_RUNNER_SERVICE_PORT_METRICS=9252 CI_MERGE_REQUEST_REF_PATH=refs/merge-requests/51/head CI_COMMIT_DESCRIPTION= Resolve NCP-1041 "Export enum utils properly" Closes NCP-1041 See merge request nl/node-ourcompany-utils!50 CI_TEMPLATE_REGISTRY_HOST=registry.gitlab.com CI_JOB_STAGE=setup CI_MERGE_REQUEST_DIFF_ID=26404 CI_PIPELINE_URL=https://git.ourcompany.com/nl/node-ourcompany-utils/-/pipelines/7803 CI_DEFAULT_BRANCH=develop CI_BUILD_REF=00d8aa19a1f4fc98aff1dafffe13258782cf036e CI_MERGE_REQUEST_TARGET_BRANCH_NAME=master CI_MERGE_REQUEST_SOURCE_BRANCH_SHA= SCAN_KUBERNETES_MANIFESTS=false CI_SERVER_VERSION_PATCH=5 CI_COMMIT_TITLE=Merge branch 'NCP-1041-export-enum-utils-properly' into 'develop' CI_DEBUG_PIPELINE=true CI_PROJECT_ROOT_NAMESPACE=nl FF_ENABLE_JOB_CLEANUP=false FF_RESOLVE_FULL_TLS_CHAIN=true RABBITMQ_DOCKER_IMAGE=git.ourcompany.com:443/nl/dependency_proxy/containers/rabbitmq:3.11-alpine GITLAB_USER_NAME=fred Johnson CI_MERGE_REQUEST_SOURCE_PROJECT_ID=140 NPM_CONFIG_USERCONFIG=/builds/nl/node-ourcompany-utils/.npmrc CI_PROJECT_DIR=/builds/nl/node-ourcompany-utils CI_MERGE_REQUEST_EVENT_TYPE=detached SONAR_TO_MARKDOWN_JQ=/builds/nl/node-ourcompany-utils.tmp/SONAR_TO_MARKDOWN_JQ SHLVL=1 CI_RUNNER_ID=67 CI_PIPELINE_CREATED_AT=2023-01-19T15:15:46Z CI_COMMIT_TIMESTAMP=2022-12-15T16:14:06+00:00 CI_DISPOSABLE_ENVIRONMENT=true CI_JOB_JWT=[MASKED] CI_USER_EMAIL=[MASKED] CI_REGISTRY_IMAGE=git.ourcompany.com:5050/nl/node-ourcompany-utils KUBERNETES_PORT_443_TCP_PROTO=tcp CI_BUILD_ID=13494 GITLAB_RUNNER_PORT_9252_TCP_ADDR=172.20.35.63 CI_SERVER_PROTOCOL=https CI_COMMIT_AUTHOR=fred Johnson <fred.johnson@ourcompany.com> KUBERNETES_PORT_443_TCP_ADDR=172.20.0.1 FF_POSIXLY_CORRECT_ESCAPES=false CI_COMMIT_REF_NAME=develop CI_SERVER_HOST=git.ourcompany.com CI_JOB_URL=https://git.ourcompany.com/nl/node-ourcompany-utils/-/jobs/13494 CI_JOB_TOKEN=[MASKED] SAST_EXCLUDED_PATHS=spec, test, tests, tmp CI_JOB_STARTED_AT=2023-01-19T15:16:08Z CI_CONCURRENT_ID=0 CI_BUILD_TOKEN=[MASKED] CI_PROJECT_DESCRIPTION= CI_PROJECT_CLASSIFICATION_LABEL= FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=false CI_RUNNER_REVISION=133d7e76 SONAR_TOKEN=[MASKED] ARTIFACT_REPO_NPM_URL_SCHEME=https CI_BUILD_BEFORE_SHA=0000000000000000000000000000000000000000 FF_KUBERNETES_HONOR_ENTRYPOINT=false FF_USE_NEW_SHELL_ESCAPE=false CI_DEPENDENCY_PROXY_USER=gitlab-ci-token FF_USE_DYNAMIC_TRACE_FORCE_SEND_INTERVAL=false FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR=false CI_PROJECT_PATH_SLUG=nl-node-ourcompany-utils POSTGRES_DOCKER_IMAGE=git.ourcompany.com:443/nl/dependency_proxy/containers/postgres:11.16-alpine CI_NODE_TOTAL=1 KUBERNETES_SERVICE_HOST=172.20.0.1 KUBERNETES_PORT=tcp://172.20.0.1:443 KUBERNETES_PORT_443_TCP_PORT=443 GITLAB_RUNNER_SERVICE_HOST=172.20.35.63 CI_BUILDS_DIR=/builds CI_JOB_ID=13494 CI_PROJECT_REPOSITORY_LANGUAGES=javascript PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin CODE_CLIMATE_CONFIG=/builds/nl/node-ourcompany-utils.tmp/CODE_CLIMATE_CONFIG CI_PROJECT_ID=140 CI=true GITLAB_CI=true CI_JOB_IMAGE=git.ourcompany.com:443/nl/dependency_proxy/containers/node:14-slim CI_COMMIT_BEFORE_SHA=0000000000000000000000000000000000000000 CI_PROJECT_TITLE=Node GraphQL Utils CI_SERVER_VERSION_MAJOR=15 GITLAB_RUNNER_PORT_9252_TCP_PORT=9252 CI_CONFIG_PATH=.gitlab-ci.yml NODE_VERSION=14.21.2 FF_USE_FASTZIP=false CI_BUILD_STAGE=setup CI_DEPENDENCY_PROXY_SERVER=git.ourcompany.com:443 GITLAB_RUNNER_PORT_9252_TCP=tcp://172.20.35.63:9252 CI_PROJECT_URL=https://git.ourcompany.com/nl/node-ourcompany-utils OLDPWD=/ REGEX_STAGING_BRANCH=/develop([-\/].*)?/ _=/usr/bin/env CI_PACKAGE_NAME=@ourcompany/node-ourcompany-utils CI_PACKAGE_VERSION=5.5.0-dev CI_RESOLVED_VERSION=5.5.0-dev.87 CI_RESOLVED_RELEASE_VERSION=5.5.0 CI_IS_STAGING_BUILD=1 CI_IS_RELEASE_BUILD=0 System: OS: Linux 5.4 Debian GNU/Linux 10 (buster) 10 (buster) CPU: (4) x64 Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz Memory: 14.12 GB / 29.90 GB Container: Yes Shell: 5.0.3 - /bin/bash Binaries: Node: 14.21.2 - /usr/local/bin/node Yarn: 1.22.19 - /usr/local/bin/yarn npm: 6.14.17 - /usr/local/bin/npm Managers: Apt: 1.8.2.3 - /usr/bin/apt Languages: Bash: 5.0.3 - /bin/bash Perl: 5.28.1 - /usr/bin/perl ; cli configs metrics-registry = "https://registry.npmjs.org/" scope = "" user-agent = "npm/6.14.17 node/v14.21.2 linux x64 ci/gitlab" ; environment configs cache = "/builds/nl/node-ourcompany-utils/.npm" userconfig = "/builds/nl/node-ourcompany-utils/.npmrc" ; userconfig /builds/nl/node-ourcompany-utils/.npmrc @ourcompany:registry = "https://artifact.ourcompany.com/repository/npm-internal/" ; node bin location = /usr/local/bin/node ; cwd = /builds/nl/node-ourcompany-utils ; HOME = /root ; "npm config ls -l" to show all defaults. section_end:1674141390:step_script [0Ksection_start:1674141390:archive_cache [0K[0K[36;1mSaving cache for successful job[0;m[0;m [32;1mCreating cache npm-cache-data-develop-non_protected...[0;m .npm*: found 28 matching files and directories [0;m Uploading cache.zip to https://our-gitlab-runner-cache.s3.dualstack.us-west-2.amazonaws.com/runner/project/140/npm-cache-data-develop-non_protected[0;m [32;1mCreated cache[0;m section_end:1674141390:archive_cache [0Ksection_start:1674141390:upload_artifacts_on_success [0K[0K[36;1mUploading artifacts for successful job[0;m[0;m [32;1mUploading artifacts...[0;m analysis/: found 2 matching files and directories [0;m Uploading artifacts as "archive" to coordinator... 201 Created[0;m id[0;m=13494 responseStatus[0;m=201 Created token[0;m=7ACnNtCb [32;1mUploading artifacts...[0;m npm.build.env: found 1 matching files and directories[0;m Uploading artifacts as "dotenv" to coordinator... 201 Created[0;m id[0;m=13494 responseStatus[0;m=201 Created token[0;m=7ACnNtCb section_end:1674141391:upload_artifacts_on_success [0Ksection_start:1674141391:cleanup_file_variables [0K[0K[36;1mCleaning up project directory and file based variables[0;m[0;m section_end:1674141392:cleanup_file_variables [0K[32;1mJob succeeded[0;m
Note that all env vars are echoed to the log and include these:
CI_DEFAULT_BRANCH=develop CI_COMMIT_REF_PROTECTED=false CI_COMMIT_REF_NAME=develop CI_BUILD_REF_SLUG=develop CI_COMMIT_REF_SLUG=develop ... Creating cache npm-cache-data-develop-non_protected...
- Laura Montemayor unassigned @lauraX
unassigned @lauraX
- Mark Nuzzo added candidate15.11 label and removed candidate15.10 label
added candidate15.11 label and removed candidate15.10 label
To establish that our current protection configuration does actually identify
develop
as a protected branch in other areas of server execution, here is a screenshot of our "Branches" view from the same project where that MR job log was captured (and identifieddevelop
as "non-protected"):Edited by Robert RossThis bug can be reproduced with the following config on my side:
workflow: rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CI_PIPELINE_SOURCE == "schedule"' - if: '$CI_COMMIT_REF_PROTECTED == "true"' - if: $CI_COMMIT_TAG stages: - debug debug: stage: debug script: - env
This way TWO pipelines will be created, one with the label
merge request
and one does not.The
merge request
job hasCI_COMMIT_REF_PROTECTED=false
andCI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED=true
.The other job has
CI_COMMIT_REF_PROTECTED=true
and noCI_MERGE_REQUEST_XXX
variables.I've also tried to check protected branches with API but it gives me a 403, I think it's because of my project token only has developer access.
- Manuel Grabowski changed the description
Compare with previous version changed the description
- Developer
The following customer is running into this issue:
- Subscription: GitLab Premium
- Product: self-managed
- Link to request: https://gitlab.zendesk.com/agent/tickets/373435
I was able to reproduce this on SaaS today and have updated the description accordingly.
1 Collapse replies - Developer
Thank you @manuelgrabowski
@marknuzzo I suggest we give this another try in %15.11
- Contributor
Thanks @manuelgrabowski for the note here and applying those updates. @dhershkovitch - I agree and I tentatively added to the newly created %15.11 planning issue for visibility so we don't lose track of it during planning. Thanks everyone.
- Contributor
@dhershkovitch - since I think grouppipeline security is at capacity for %15.11, I'm going to change the candidate label to candidate16.1 for now. @jocelynjane @morefice - please adjust accordingly and Dov - I'll remove from our planning issue since it's now under grouppipeline security
3 1 - Developer
I believe that before that its probably worth working on #29674 (closed) which holds higher priority IMO
/cc @jocelynjane
1 - Developer
Thanks for the feedback @dhershkovitch - I've swapped the order of the two.
- Mark Nuzzo mentioned in issue gitlab-org/ci-cd/pipeline-authoring#89 (closed)
mentioned in issue gitlab-org/ci-cd/pipeline-authoring#89 (closed)
- Tiffany Rea mentioned in issue gitlab-org/quality/quality-engineering/team-tasks#1635 (closed)
mentioned in issue gitlab-org/quality/quality-engineering/team-tasks#1635 (closed)
- Maintainer
Setting label(s) Category:Pipeline Composition based on grouppipeline authoring.
- Dov Hershkovitch added grouppipeline security label and removed grouppipeline authoring label
added grouppipeline security label and removed grouppipeline authoring label
- 🤖 GitLab Bot 🤖 added grouppipeline authoring label and removed grouppipeline security label
added grouppipeline authoring label and removed grouppipeline security label
- Tiffany Rea added grouppipeline security label and removed grouppipeline authoring label
added grouppipeline security label and removed grouppipeline authoring label
- Mark Nuzzo changed milestone to %15.11
changed milestone to %15.11
- Mark Nuzzo changed milestone to %Backlog
changed milestone to %Backlog
- Mark Nuzzo added candidate16.1 label and removed candidate15.11 label
added candidate16.1 label and removed candidate15.11 label
- Max Orefice removed [deprecated] Accepting merge requests label
removed [deprecated] Accepting merge requests label
- Jocelyn Eillis removed candidate16.1 label
removed candidate16.1 label
- Jocelyn Eillis added candidate16.2 label
added candidate16.2 label
- Sofia Vistas mentioned in issue gitlab-org/quality/quality-engineering/team-tasks#1759 (closed)
mentioned in issue gitlab-org/quality/quality-engineering/team-tasks#1759 (closed)
- 🤖 GitLab Bot 🤖 added sectionci label and removed sectionops label
added sectionci label and removed sectionops label
We're also affected by this issue. In our case Vault integration is broken - we only allow Vault access from protected branches and in MR Pipelines custom ID Token has
ref_protected
claim set tofalse
.Edited by Szymon Soloch 1Collapse replies
- Contributor
@dhershkovitch do you have any news regarding working on this item for the next release?
Collapse replies - Developer
Pinging @jocelynjane since she is the DRI for CI variables
- Developer
Thanks for the ping @dhershkovitch!
@r.leite - this is not currently planned due to some of the other higher priority items we have. Happy to chat more and see if there is additional customer feedback to be aware of in prioritizing. Thanks!
- Developer
GitLab Premium customer would like to see this fixed.
Zendesk Ticket - internal
- Vincy Wilson mentioned in issue gitlab-org/quality/quality-engineering/team-tasks#1993 (closed)
mentioned in issue gitlab-org/quality/quality-engineering/team-tasks#1993 (closed)
- Jocelyn Eillis added reproduced on GitLab.com label
added reproduced on GitLab.com label
I am also struggling with that issue: jobs are not able to access protected variables, despite both source and target branches being protected, which makes no sense. Looking forward to this problem being fixed.
Hi!
Dumb question for pipeline authoring dev: is there a way to enable debug in pipeline creation on a self-deployed instance? And where to find logs related to that?
Still can't figure out why I get the following env for my MR jobs and thus can't use any protected variable:
CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED=true CI_MERGE_REQUEST_SOURCE_BRANCH_PROTECTED=true CI_COMMIT_REF_PROTECTED=false
If I manually run the same pipeline on the branch overriding with
CI_PIPELINE_SOURCE="merge_request_event"
I do get the protected env and variables.Thanks!
Edited by Basile PinsardLooking into the pipeline records in the rails console, the merge request pipelines all have
jobs_git_ref
attr set tonil
, it is supposed to be an alias_method togit_ref
and a comment mentions it being overridden in the class, but I can't find any line that touches that variable (grepped the full repo).https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/ci/pipeline.rb#L51
Digging into gitlab code (first-time, haven't used ruby in decades, so might be wrong) I can guess out that:
even if the
alias_method
was not overridden bynil
, with my pipelinesref
being something likerefs/merge-requests/1/head
protected_ref? https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/variables/builder.rb?ref_type=heads#L190-194
calls protected_for
https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/project.rb?ref_type=heads#L2519-2536
that never get past
resolved_ref = repository.expand_ref(ref) || ref
as
expand_ref
only check for tags or branches.https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/repository.rb?ref_type=heads#L255-261
So I don't understand where
jobs_git_ref
gets overridden in the first place and get assigned a nil value, whether it is supposed to be set to the MR branch ref for the pipeline to be considered protected.Looking at the code, this bug should affect all users, so I don't understand how @lauraXD got it working in their tests.
Using a recent docker image with v16.8.2-ee.
2ct regarding above: maybe
jobs_git_ref
is set on the fly in another place and not recorded in the database givingnil
when retrieve in the console.Now looking into what
git_ref
is supposed to assigned:Exploring the pipeline object through the rails console, these refs don't make sense!?
irb(main):060:0> pipelines[3].send(:git_ref) => "refs/heads/refs/merge-requests/2/head" irb(main):061:0> pipelines[3].clear_memoization(:git_ref) => "refs/heads/refs/merge-requests/2/head" irb(main):062:0> pipelines[3].send(:git_ref) => "refs/heads/refs/merge-requests/2/head"
ci_ref
attr seems to hold the correct value (branch name) to check for branch protection (here source branch).irb(main):091:0> pipelines[3].ci_ref => #<Ci::Ref:0x00007fbd982d7500 id: 193, project_id: 227, lock_version: 1, status: 1, ref_path: "refs/heads/convert/p01_ana010">
Hope all these infos can help to find a solution, if this is not replicable on your side.
`
jobs_git_ref`
is apparently expected to be nil on MR pipelines !Going back to https://gitlab.com/lauraXD/demo-project @lauraXD 's test
If you apply that patch to the pipeline, it results in
CI_COMMIT_REF_PROTECTED=false
for usecase 3 (protected to protected).check_variables: + rules: + - if: $CI_PIPELINE_SOURCE == "merge_request_event" script: - env
So when limiting the job to only run on merge requests, it looses the protected env, which is counter-intuitive and problematic.
3- Developer
Another GitLab Premium customer has reached out about this problem via this (internal only) ticket; Though this seems to indirectly affect token payloads, the underlying issue appears to be the same
1 - Jocelyn Eillis added to epic &13027
added to epic &13027
- Jocelyn Eillis removed candidate16.2 label
removed candidate16.2 label
- Jocelyn Eillis removed Category:Pipeline Composition label
removed Category:Pipeline Composition label
- Jocelyn Eillis added Category:Secrets Management label
added Category:Secrets Management label
- Jocelyn Eillis changed milestone to %Next 1-3 releases
changed milestone to %Next 1-3 releases
- Vincy Wilson mentioned in issue gitlab-com/Product#13216 (closed)
mentioned in issue gitlab-com/Product#13216 (closed)
- Vincy Wilson mentioned in issue gitlab-com/Product#13289 (closed)
mentioned in issue gitlab-com/Product#13289 (closed)
- Developer
A very large GitLab Ultimate SaaS customer has (I believe) run into this issue when trying to resolve Vault secrets in MR pipelines where both source and target branches are protected, and the
ref_protected: true
claim is bound to the Vault role. While branch pipelines and manual pipelines run OK, MR pipelines fail due to the ID token havingref_protected: false
which I strongly suspect is due to the same bug causing theCI_COMMIT_REF_PROTECTED
variable to have the wrong value. (ZD internal link) - Jocelyn Eillis changed milestone to %Next 4-6 releases
changed milestone to %Next 4-6 releases
- Vincy Wilson mentioned in issue gitlab-com/Product#13358 (closed)
mentioned in issue gitlab-com/Product#13358 (closed)
- 🤖 GitLab Bot 🤖 added Category:Variables grouppipeline authoring labels and removed grouppipeline security label
added Category:Variables grouppipeline authoring labels and removed grouppipeline security label
- 🤖 GitLab Bot 🤖 added Category:Pipeline Composition label
added Category:Pipeline Composition label
- Jocelyn Eillis removed Category:Secrets Management label
removed Category:Secrets Management label
- Mark Nuzzo changed milestone to %Backlog
changed milestone to %Backlog
- Manuel Grabowski changed the description
Compare with previous version changed the description
- Max Orefice changed the description
Compare with previous version changed the description
- DeveloperResolved by Chris Stone
I'm wondering if this would also impact the initial commit where the branch is yet to exist, including the default branch? A GitLab Premium customer identified (internal link)
CI_COMMIT_REF_PROTECTED
as beingfalse
on the initial commit. I could also reproduce the same.Not sure if that behaviour is related to this issue or warrants a separate one.
To reproduce via the UI (also same behaviour with initial
git push
)- Create blank project (no README)
- Use the following in pipeline editor:
protected: rules: - if: '$CI_COMMIT_REF_PROTECTED == "true"' script: - env | sort not-protected: rules: - if: '$CI_COMMIT_REF_PROTECTED == "false"' script: - env | sort
- Observe that
not-protected
job runs
I can't imagine this is the expected behaviour, especially as the default branch is supposed to be protected by default?
3 replies Last reply by Chris Stone
- Chris Stone mentioned in issue #474179 (closed)
mentioned in issue #474179 (closed)
- Dov Hershkovitch added candidate17.5 label
added candidate17.5 label
- Max Orefice mentioned in merge request !161159 (closed)
mentioned in merge request !161159 (closed)
- Scott Hampton marked this issue as related to #420463
marked this issue as related to #420463
- Scott Hampton mentioned in issue #420463
mentioned in issue #420463
- Dov Hershkovitch added candidate17.6 label and removed candidate17.5 label
added candidate17.6 label and removed candidate17.5 label
- Maintainer
Adding weight-2 and marking as workflowready for development
- Furkan Ayhan added workflowready for development label and removed workflowplanning breakdown label
added workflowready for development label and removed workflowplanning breakdown label
- Furkan Ayhan set weight to 2
set weight to 2
- Developer
I have a customer experiencing this problem, but with a slight difference. In their case it seems that the variable is always true, even if the branch isn't protected. See: https://gitlab.zendesk.com/agent/tickets/560858 (internal only)
we have the opposite direction, but only for merge request pipelines. It seems that the $CI_COMMIT_REF_PROTECTED is true even if the source branch isn't protected. However, seems to be related to the code mentioned in the issue.
- Dov Hershkovitch mentioned in issue gitlab-com/Product#13611
mentioned in issue gitlab-com/Product#13611
- Viktor Nagy (GitLab) added co-create label
added co-create label
- Contributor
To be clear: whether or not the Merge Request ref is protected should be determined by both the source and target branch right? And only be marked as protected and have access to protected variables only if both source and target are protected branches?
Otherwise I think you might open an attack vector when using Merged Result and/or Merge Train by creating a Merge Request between a protected source branch and a malicious target branch (and vice versa?
) where you can extract these protected variables or access resources that shouldn't be accessed. - Maina Ng'ang'a mentioned in epic gitlab-com/gl-infra#1335
mentioned in epic gitlab-com/gl-infra#1335
- service-epic-status-automation mentioned in epic gitlab-com/gl-infra&1335
mentioned in epic gitlab-com/gl-infra&1335
- service-epic-status-automation mentioned in epic gitlab-com/gl-infra&170
mentioned in epic gitlab-com/gl-infra&170
- Jackie Porter removed candidate17.6 label
removed candidate17.6 label
- Nick Veenhof added community-bonus300 label
added community-bonus300 label
A quick workaround that seems to work, at least for one of our project : protect branches that are named "refs/merge-requests/*". This way, the ephemeral internal branch that seems to host the MR will be protected. But that's no substitute for a real fix for the MR request protected status, as there seems to be something fishy about it.
Collapse replies Interesting, thanks! But it seems that it could be an important security issue if that allows any MR (including ones from non-protected branches) to access secrets...
Ultimate Customer running into this problem. Needs fix!
The scenario is that there is an integration MR which source branch is protected (target as well but should not matter).
CI_COMMIT_REF_PROTECTED
evaluates tofalse
.
This is currently blocking a pipeline design when you want to distinguish between a MR pipeline and disable MR specific jobs while keeping protected jobs.
The protected ref variable should have presendence over the rest. That there is an additional MR for this protected ref should not matter in that case, that the ref is protected is the important thing for that pipeline.