Gate flow workload variables on owner opt-in and allowlist

What does this MR do and why?

Makes project and group CI/CD variables available to flow workloads when both gates are met:

1. The owner selected Allow in GitLab Duo Agent Platform workloads on the variable (MR 4a/4b).
2. The key is listed under variables in .gitlab/duo/agent-config.yml (MR 2).

• Gitlab::Ci::Variables::Builder::{Project,Group} filter requested keys with new allowed_in_workloads scopes; Builder::Instance returns nothing for workload requests.
• Ai::DuoWorkflows::StartWorkflowService passes the allowlisted keys (minus reserved workload names) to the workload and unmasks them in the job.
• Masking, file type, environment scope and protected-ref behavior (MR 3) are preserved.
• Documents the setting and the variables key.

Behavior change for flow triggers: Ai::FlowTriggers::RunService already passed a flow definition's variables without any opt-in. Those variables are now only resolved when the owner selected the checkbox, and instance variables are no longer resolved (Changelog: changed commit, documented).

The first commit is MR 2 and disappears after MR 2 merges and this branch is rebased.

References

• Work item: #602887
• Split of !252729 (the original, now the final MR):

#	Merge request	Base
1	!254470 (merged) Add columns	master
2	!254471 (merged) Parse variables in agent-config.yml	master
3	!254472 Persist source ref protection	1
4a	!254473 Expose allowed_in_workloads on APIs	1
4b	!254474 Settings checkbox	4a
5	!252729 Gate workload variables (feature becomes active)	3, needs 2

Screenshots or screen recordings

Not applicable: no UI change (see MR 4b).

How to set up and validate locally

1. In a project, create variable MY_API_TOKEN and select Allow in GitLab Duo Agent Platform workloads. Create OTHER_TOKEN without it.

2. On the default branch, add to .gitlab/duo/agent-config.yml:

   variables:
     - MY_API_TOKEN
     - OTHER_TOKEN

3. Run a flow and open its CI job log (printenv in a custom flow step, or inspect the job's variables): MY_API_TOKEN is present, OTHER_TOKEN is not.

4. Remove MY_API_TOKEN from the YAML and rerun: it is absent.

5. Mark MY_API_TOKEN as Protect variable. Start the flow from an unprotected branch: absent. From a protected branch: present.

6. Create an instance variable (Admin > CI/CD > Variables) and list it in the YAML: never present.

7. Mark MY_API_TOKEN masked: its value shows as [MASKED] in the job log.

Database queries

CI database. allowed_in_workloads is a boolean filter applied after the existing unique indexes; no new index. Rows are bounded by the project or group hierarchy and the 50-key maximum. Query plans: pending (postgres.ai links to follow).

Project variables (index_ci_variables_on_project_id_and_key_and_environment_scope; protected-ref variant omits "protected" = FALSE):

SELECT "ci_variables".* FROM "ci_variables"
WHERE "ci_variables"."project_id" = 278964
  AND "ci_variables"."protected" = FALSE
  AND (environment_scope IN ('*', 'production')
       OR 'production' LIKE REPLACE(REPLACE(REPLACE(environment_scope, '%', '\%'), '_', '\_'), '*', '%'))
  AND "ci_variables"."allowed_in_workloads" = TRUE
  AND "ci_variables"."key" IN ('ALLOWED_ONE', 'ALLOWED_TWO')
ORDER BY CASE environment_scope WHEN '*' THEN 0 WHEN 'production' THEN 2 ELSE 1 END ASC;

Group variables (index_ci_group_variables_on_group_id_and_key_and_environment; group_id IN is the existing self-and-ancestors list):

SELECT "ci_group_variables".* FROM "ci_group_variables"
WHERE "ci_group_variables"."group_id" IN (9970)
  AND "ci_group_variables"."protected" = FALSE
  AND (environment_scope IN ('*', 'production')
       OR 'production' LIKE REPLACE(REPLACE(REPLACE(environment_scope, '%', '\%'), '_', '\_'), '*', '%'))
  AND "ci_group_variables"."allowed_in_workloads" = TRUE
  AND "ci_group_variables"."key" IN ('ALLOWED_ONE', 'ALLOWED_TWO')
ORDER BY CASE environment_scope WHEN '*' THEN 0 WHEN 'production' THEN 2 ELSE 1 END ASC;

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.