Bogdan Denkovych activity

Bogdan Denkovych opened incident #2737: GDK Troubleshooting Report 94ced8b6-a9e6-4947-9a7b-a43dc44e6eb3: `gdk install` does not set up test databases at GitL...

2026-03-17T20:52:57Z

After new gdk instance install, following "Simple installation" guide, and running any spec, like bin/rspec ee/spec/models/ee/group_spec.rb:965, I see the following issue:

~/gdk/gitlab$ bin/rspec ee/spec/models/ee/group_spec.rb:965
Creating a backup of secrets file /home/bogdanvlviv/gdk/gitlab/config/secrets.yml at /home/bogdanvlviv/gdk/gitlab/tmp/tests/backups/secrets.yml.orig.1749764350

An error occurred while loading ./ee/spec/models/ee/group_spec.rb.
Failure/Error: super(connection, underlying_table(connection, table_name))

ActiveRecord::StatementInvalid:
  PG::UndefinedTable: ERROR:  relation "application_settings" does not exist
  LINE 10:  WHERE a.attrelid = '"application_settings"'::regclass
                               ^
# ./lib/gitlab/database/schema_cache_with_renamed_table.rb:25:in `columns'
# ./lib/gitlab/database/schema_cache_with_renamed_table.rb:29:in `columns_hash'
# ./app/models/concerns/cacheable_attributes.rb:31:in `build_from_defaults'
# ./lib/gitlab/application_setting_fetcher.rb:52:in `in_memory_application_settings'
# ./lib/gitlab/application_setting_fetcher.rb:25:in `cached_application_settings'
# ./lib/gitlab/application_setting_fetcher.rb:11:in `current_application_settings'
# ./lib/gitlab/current_settings.rb:15:in `block in current_application_settings'
# ./gems/gitlab-safe_request_store/lib/gitlab/safe_request_store/null_store.rb:37:in `fetch'
# ./lib/gitlab/current_settings.rb:15:in `current_application_settings'
# ./lib/banzai/filter/asset_proxy_filter.rb:67:in `initialize_settings'
# ./config/initializers/asset_proxy_settings.rb:7:in `block in '
# ./config/initializers/asset_proxy_settings.rb:6:in `'
# ./config/environment.rb:7:in `'
# ./spec/spec_helper.rb:27:in `require_relative'
# ./spec/spec_helper.rb:27:in `'
# ./ee/spec/models/ee/group_spec.rb:3:in `'
# ------------------
# --- Caused by: ---
# PG::UndefinedTable:
#   ERROR:  relation "application_settings" does not exist
#   LINE 10:  WHERE a.attrelid = '"application_settings"'::regclass
#                                ^
#   ./lib/gitlab/database/schema_cache_with_renamed_table.rb:25:in `columns'
Run options: include {:locations=>{"./ee/spec/models/ee/group_spec.rb"=>[965]}}

All examples were filtered out

Finished in 0.00004 seconds (files took 5.09 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples

To resolve that issue I had to run RAILS_ENV=test bin/rails db:setup. I didn't need to do that manually in the past.

Steps to replicate (optional)

Environment

General

Operating System: Linux 6.11.0-26-generic #26~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr 17 19:20:47 UTC 2 x86_64 x86_64 GNU/Linux
Architecture: x86_64
Ruby Version: ruby 3.3.8 (2025-04-09 revision b200bad6cd) [x86_64-linux]
GDK version: aac934e0
Package Manager: mise-en-place 2025.6.1 linux-x64 (2025-06-09)

Variables

Bogdan Denkovych deleted project branch 20184-gpat-on-credentials at GitLab.org / GitLab

2026-03-17T13:36:47Z

Bogdan Denkovych (debf7240) at 17 Mar 13:36

Bogdan Denkovych pushed to project branch master at GitLab.org / GitLab

2026-03-17T13:36:03Z

Bogdan Denkovych (3fbbe9ea) at 17 Mar 13:36

Merge branch '20184-gpat-on-credentials' into 'master'

... and 1 more commit

Bogdan Denkovych accepted merge request !222002: Show granular personal access tokens on credentials page at GitLab.org / GitLab

2026-03-17T13:35:23Z

What does this MR do and why?

Show granular personal access tokens on Credentials page
If the personal access token is granular, then show permissions and access for each granular scope

Screenshots or screen recordings

How to set up and validate locally

Enable feature-flag in rails console:

Feature.enable(:granular_personal_access_tokens)

Log-in as admin.
Create a granular personal access token by navigating to Preferences > Personal access tokens.
Then, navigate to the Admin area and navigate to Credentials to see the token.
Disable the feature-flag in rails console and refresh the page:

Feature.disable(:granular_personal_access_tokens)

You should see the token but with an Inactive warning message.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to gitlab-org#20184

Bogdan Denkovych approved merge request !222785: Add Email OTP enrollment rake tasks at GitLab.org / GitLab

2026-03-17T12:47:38Z

What does this MR do and why?

Implements three Rake tasks for managing Email OTP enrollment, in support of mandatory Email OTP enforcement on GitLab.com and, for those that want it, eventually on self-managed instances. Closes #589173.

Tasks added

gitlab:email_otp:enrol — Sets email_otp_required_after in bulk for all in-scope users. Defaults to DRY_RUN=true so it can be used safely to count affected users before committing.

Supports three operational modes:

Mode	Parameters	Effect
Enrol new users	`ENROL_AT=`	Sets enrollment date for all in-scope users not yet enrolled
Shift a cohort	`ENROL_AT= EXISTING_ENROL_AT=`	Moves a specific cohort to a new date
Revert a cohort	`EXISTING_ENROL_AT=`	Clears enrollment for a specific cohort (sets to `NULL`)

The latter two in particular can be used to rollback / revert an enrolment.

gitlab:email_otp:enforce — Enables require_minimum_email_based_otp_for_users_with_passwords instance setting.

gitlab:email_otp:unenforce — Disables the same setting.

In-scope user definition

A user is in scope for new enrollment when all of the following are true:

users.state = 'active' and users.user_type = 0 (human, non-bot)
users.password_automatically_set = false (self-set password)
users.otp_required_for_login = false (no TOTP)
No WebAuthn registrations with authentication_mode = 2 (second-factor)
user_details.email_otp_required_after IS NULL (not already enrolled)

Expected operator workflow

# 1. Dry-run to see how many users are in scope
bundle exec rake gitlab:email_otp:enrol ENROL_AT=2027-01-01T00:00:00Z

# 2. Enrol for real
bundle exec rake gitlab:email_otp:enrol DRY_RUN=false ENROL_AT=2027-01-01T00:00:00Z

# 3. Confirm count is now 0
bundle exec rake gitlab:email_otp:enrol ENROL_AT=2027-01-01T00:00:00Z

# 4. Enable enforcement
bundle exec rake gitlab:email_otp:enforce

For rollback or date-shifting a cohort:

# Shift cohort
bundle exec rake gitlab:email_otp:enrol DRY_RUN=false ENROL_AT=2027-02-01T00:00:00Z EXISTING_ENROL_AT=2027-01-01T00:00:00Z

# Revert cohort to unenrolled
bundle exec rake gitlab:email_otp:enrol DRY_RUN=false EXISTING_ENROL_AT=2027-01-01T00:00:00Z

Example run

My GDK has a tiny number of rows, but to give a sense of the script output:

Click to expand

Bogdan Denkovych approved merge request !225580: Protected Terraform States: Add database migration and model [PART 1] at GitLab.org / GitLab

2026-03-17T11:13:28Z

What does this MR do and why?

Create the data layer for Terraform state protection rules, enabling project maintainers to define rules that restrict who can write to a Terraform state based on project role and request source (PAT, CI job, CI on protected branch).

This is the foundational MR (1 of 7) for the protected Terraform states feature. It creates the terraform_state_protection_rules database table and the Terraform::StateProtectionRule model following the packages_protection_rules pattern.

What's included:

Database migration creating terraform_state_protection_rules with:
- project_id FK (cascade delete)
- state_name (text, max 255 chars) — exact match against Terraform state name
- minimum_access_level_for_write (smallint enum: developer, maintainer, owner, admin)
- allowed_from (smallint enum: anywhere, ci_only, ci_on_protected_branch_only)
- Unique composite index on (project_id, state_name)
Model (Terraform::StateProtectionRule) with enums using Gitlab::Access constants, validations, and for_state_name scope
Project association: has_many :terraform_state_protection_rules
Factory and full model spec (14 examples)
Database dictionary YAML metadata

No behavior changes yet — rules can only be created via Rails console. Enforcement, CRUD services, API endpoints, and UI follow in subsequent MRs.

🛠️ with ❤️ at Siemens

References

Epic: &15118
POC MR: !224329
Reference pattern: packages_protection_rules

Screenshots or screen recordings

Not applicable — backend-only changes.

How to set up and validate locally

Run the migration: bundle exec rails db:migrate

Open Rails console and create a rule:

project = Project.first
rule = project.terraform_state_protection_rules.create!(
  state_name: 'production',
  minimum_access_level_for_write: :maintainer,
  allowed_from: :ci_only
)

Verify uniqueness — creating a second rule with the same project and state name raises ActiveRecord::RecordInvalid
Verify cascade delete — deleting the project also deletes associated protection rules
Verify the association: project.terraform_state_protection_rules returns the created rules
Verify the scope: Terraform::StateProtectionRule.for_state_name('production') returns matching rules

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

MR Checklist (@gerardo-navarro)

Bogdan Denkovych approved merge request !222002: Show granular personal access tokens on credentials page at GitLab.org / GitLab

2026-03-17T10:55:15Z

What does this MR do and why?

Show granular personal access tokens on Credentials page
If the personal access token is granular, then show permissions and access for each granular scope

Screenshots or screen recordings

How to set up and validate locally

Enable feature-flag in rails console:

Feature.enable(:granular_personal_access_tokens)

Log-in as admin.
Create a granular personal access token by navigating to Preferences > Personal access tokens.
Then, navigate to the Admin area and navigate to Credentials to see the token.
Disable the feature-flag in rails console and refresh the page:

Feature.disable(:granular_personal_access_tokens)

You should see the token but with an Inactive warning message.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to gitlab-org#20184

Bogdan Denkovych commented on issue #35251 at GitLab.com / www-gitlab-com

2026-03-12T17:45:51Z

Protected Terraform States: Add database migration and model [PART 1]: gitlab-org/gitlab!225580 (merged)

During review:

Reviewed the migration.
Triggered db:gitlabcom-database-testing job and reviewed its output gitlab-org/gitlab!225580 (comment 3155212947).

Post-review:

gitlab-org/gitlab!225580 (comment 3157350230)
- I missed ordering table columns.

@bmarjanovic please add feedback, and compare this review to the average maintainer review.

Bogdan Denkovych commented on merge request !225580 at GitLab.org / GitLab

2026-03-12T16:33:19Z

@bmarjanovic Could you please provide database maintainer review?

Bogdan Denkovych commented on merge request !225580 at GitLab.org / GitLab

2026-03-12T16:32:20Z

@gerardo-navarro This MR LGTM from database perspective. I left a few backend suggestions.

Bogdan Denkovych commented on merge request !225580 at GitLab.org / GitLab

2026-03-12T16:08:33Z

Let's also add spec for this in spec/models/project_spec.rb.

Bogdan Denkovych commented on merge request !225580 at GitLab.org / GitLab

2026-03-12T16:06:55Z

As per suggestion to remove for_state_name scope.

Bogdan Denkovych commented on merge request !225580 at GitLab.org / GitLab

2026-03-12T16:06:54Z

Rails scopes always return a collection. Since a project cannot have multiple terraform_state_protection_rules with the same state_name, we will probably rely on Rails find_by_* method, like project.terraform_state_protection_rules.find_by_state_name. Let's remove this scope?

Bogdan Denkovych commented on issue #592520 at GitLab.org / GitLab

2026-03-12T13:13:58Z

If we wanted to really accurate (and it might be overkill unless the FF stays in the system longer)

I agree.

To correctly disable granular token for authentication by the FF, it should be checked in PersonalAccessToken.find_by_token method for the related user instead.

I think this is important.

Bogdan Denkovych approved merge request !222002: Show granular personal access tokens on credentials page at GitLab.org / GitLab

2026-03-12T13:08:17Z

What does this MR do and why?

Show granular personal access tokens on Credentials page
If the personal access token is granular, then show permissions and access for each granular scope

Screenshots or screen recordings

How to set up and validate locally

Enable feature-flag in rails console:

Feature.enable(:granular_personal_access_tokens)

Log-in as admin.
Create a granular personal access token by navigating to Preferences > Personal access tokens.
Then, navigate to the Admin area and navigate to Credentials to see the token.
Disable the feature-flag in rails console and refresh the page:

Feature.disable(:granular_personal_access_tokens)

You should see the token but with an Inactive warning message.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to gitlab-org#20184

Bogdan Denkovych commented on merge request !222002 at GitLab.org / GitLab

2026-03-12T13:08:01Z

Changes in this file may conflict with !227027 (merged). Let's revert all changes in this file for this MR?

Bogdan Denkovych approved merge request !227027: Revert "Merge branch '589499-show-gpat-as-inactive' into 'master'" at GitLab.org / GitLab

2026-03-12T13:02:29Z

What does this MR do and why?

Revert "Merge branch '589499-show-gpat-as-inactive' into 'master'"

This reverts merge request !224006

References

https://gitlab.com/gitlab-org/gitlab/-/work_items/592892

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Bogdan Denkovych commented on merge request !227027 at GitLab.org / GitLab

2026-03-12T12:03:55Z

We should keep this feature_category to make CI pass.

RSpec.describe API::Entities::PersonalAccessToken, feature_category: :system_access do

Bogdan Denkovych commented on issue #592520 at GitLab.org / GitLab

2026-03-11T14:25:43Z

@hmehra @alexbuijs See !222002 (comment 3150702867).

I skimmed over the existing granular_personal_access_tokens FF checks. It looks like we incorrectly apply granular_personal_access_tokens FF. We should check granular_personal_access_tokens for current_user only for creating token and for user_settings pages. In other cases, the FF should be checked for personal_access_token.user. Correct?

What concerns me the most is the FF check in https://gitlab.com/gitlab-org/gitlab/-/blob/607bbb317dbf996e515315033ea67170b8065318/app/finders/personal_access_tokens_finder.rb#L81. There is no guarantee that current_user is always present in that context, for instance see https://gitlab.com/gitlab-org/gitlab/-/blob/607bbb317dbf996e515315033ea67170b8065318/lib/gitlab/auth.rb#L301-L304. Meaning that currently the FF could allow users manage granular tokens, but they won't be able to use them/authenticate with them until the FF is globally enabled.

To correctly disable granular token for authentication by the FF, it should be checked in PersonalAccessToken.find_by_token method for the related user instead.