[BUG] GitLab (self-hosted) org-policy auto-discovery is impossible: all candidate repo names are invalid GitLab project paths

[rrazvd]

Describe the bug
On self-hosted GitLab, APM org-policy auto-discovery can never resolve, because every candidate repository name in the discovery cascade is an invalid GitLab project path.

Per the Policy Files docs, discovery probes, in order: .github-private → .github → .apm → _apm. GitLab rejects any project path that starts with ., _, or -:

Path can only include non-accented letters, digits, '', '-' and '.'. It must not start with '-', '', or '.', nor end with '-', '_', '.', '.git', or '.atom'.

So none of the four candidates can be created:

Candidate	Valid on GitLab?	Reason
.github-private	❌	leading .
.github	❌	leading .
.apm	❌	leading .
_apm	❌	leading _

This is stricter than Azure DevOps (#2429): ADO forbids a leading _ only on the project name, so PR #2450 could keep repository _apm inside project apm. On GitLab the _apm fallback is also invalid, so there is no working coordinate at all. Additionally, probing these paths on our host surfaces an HTTP 410, which prints a policy-fetch warning on every apm install / apm audit (inconsistent with the docs stating GitLab "falls through with no policy applied").

To Reproduce
Steps to reproduce the behavior:

1. On a project whose origin is a self-hosted GitLab remote (git@gitlab.example.com:<group>/<repo>.git), run command apm audit --ci (without --no-policy), or apm install.
2. With parameters: default org-policy auto-discovery (no explicit --policy).
3. See error: a policy-fetch warning (HTTP 410 on our host) and no org policy applied. Then try to create the org policy repo under the group — GitLab rejects .github-private, .github, .apm, and _apm with the path error quoted above.

Expected behavior
A supported way to host and auto-discover org policy on self-hosted GitLab using a valid, configurable GitLab project path (e.g. apm-policy), plus a clean "no policy" outcome (not a 410 warning) when none is present — analogous to the ADO project-coordinate fix in PR #2450, but for GitLab where even _apm is an invalid path.

Environment:

• OS: macOS
• APM Version: 0.25.0
• Git host: self-hosted GitLab (GitLab Enterprise), e.g. gitlab.example.com

Logs
The form contains the following errors:

• Project namespace path can only include non-accented letters, digits, '', '-' and '.'. It must not start with '-', '', or '.', nor end with '-', '_', '.', '.git', or '.atom'.
• Path can only include non-accented letters, digits, '', '-' and '.'. It must not start with '-', '', or '.', nor end with '-', '_', '.', '.git', or '.atom'.

Additional context
Current mitigation is apm audit --ci --no-policy, which disables policy enforcement entirely.

Proposed direction:

1. Configurable / host-valid policy repo name (default e.g. apm-policy), mirroring PR fix(policy): use valid ADO project coordinate #2450's ADO project-coordinate fix but for GitLab (where _apm is invalid too).
2. A GitLab auto-discovery code path (currently documented as "not auto-discovered / falls through with no policy").
3. apm install --policy <path-or-url> for install-time enforcement on non-GitHub remotes (tracked more broadly in [FEATURE] Support policy enforcement on non-GitHub remotes: add --policy to apm install (and/or auto-discovery for GitLab/ADO/plain git) #1925).
4. Treat a missing policy repo as a clean "no policy" outcome instead of emitting an HTTP 410 warning.

Related:

• [FEATURE] Support policy enforcement on non-GitHub remotes: add --policy to apm install (and/or auto-discovery for GitLab/ADO/plain git) #1925 — umbrella feature: policy enforcement on non-GitHub remotes (--policy on install and/or GitLab/ADO/plain-git auto-discovery).
• [BUG] Azure DevOps and apm-policy.yml #2429 + fix(policy): use valid ADO project coordinate #2450 — the ADO analogue (invalid policy project coordinate), fixed for ADO only.

[github-actions]

Triage Panel Verdict -- #2566

Issue: [BUG] GitLab (self-hosted) org-policy auto-discovery is impossible: all candidate repo names are invalid GitLab project paths
Author: @rrazvd (contributor)
Version reported: APM 0.25.0, macOS, self-hosted GitLab Enterprise

---

Panel synthesis

DevX UX Expert: Thorough, well-evidenced report. The user documents why all four auto-discovery candidate names (.github-private, .github, .apm, _apm) violate GitLab's project path constraints. Additionally, the 410 HTTP warning surfaced on every apm install / apm audit call when no policy repo exists degrades the UX: it looks like an error for users who deliberately have no org policy, not a clean no-op.

Supply Chain Security Expert: This is not just UX -- it is a governance gap. Enterprise teams on self-hosted GitLab cannot enforce org policy through APM at all. They are forced to run with --no-policy, disabling a key compliance surface. The apm audit --ci path, used in CI pipelines, becomes unenforceable on GitLab. High priority from a security posture perspective.

Python Architect: The ADO analogue (issue #2429, PR #2450) is the direct reference implementation. The fix requires a GitLab-specific policy discovery path that (a) uses valid GitLab project-path names (e.g. apm-policy), (b) is configurable or defaults to a sensible valid name, and (c) treats a missing policy repo as a clean no-op (no 410 warning). The four proposed directions in the issue body are well-scoped and accurate.

OSS Growth Hacker: Self-hosted GitLab is the most common enterprise alternative to GitHub. Fixing auto-discovery here is a significant enterprise unlock. The author is a CONTRIBUTOR -- this is high-quality signal from someone actively trying to deploy APM in production.

APM CEO: LEGIT -- high priority. The ADO fix (PR #2450) exists as a template. Enterprise GitLab is a large segment and a primary sales/adoption target. The 410 warning on every install is a recurring visible regression for any org that evaluates APM on GitLab. Prioritize for the next minor alongside related issue #1925.

---

Decision

Dimension	Value
Type	Bug
Area	Enterprise, Audit/Policy
Theme	Governance
Priority	High
Milestone	Next minor (suggest: 0.29.0)
Status	Triaged

Proposed labels: type/bug, area/enterprise, area/audit-policy, theme/governance, priority/high, status/triaged
(Note: type/bug was already present on the issue; all labels above should be applied.)

Suggested next action: A maintainer should implement a GitLab-specific policy discovery path -- mirroring the ADO fix in PR #2450 -- using a valid default GitLab project name (e.g. apm-policy) with optional configuration override. Additionally fix the 410 warning to emit nothing (silent no-op) when the candidate repo does not exist, consistent with the documented behavior ("falls through with no policy applied"). Cross-reference with umbrella issue #1925 for broader non-GitHub policy enforcement.

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · 56.1 AIC · ⌖ 7.92 AIC · ⊞ 9.2K · ◷