Trusted Publisher: GitLab CI/CD namespace field docs unclear for nested subgroups, UI accepts invalid config silently

[gecube]

Summary

When configuring a Trusted Publisher for GitLab CI/CD on npmjs.com, the "Namespace" field is described as "Your
GitLab username or group name." For projects nested under subgroups (e.g., gitlab.com/org/sub1/sub2/project),
it's unclear that the full subgroup path must be entered as the namespace. The UI accepts an incorrect split
between namespace and project without validation, resulting in a confusing 404 error during OIDC token exchange
at publish time.

Steps to Reproduce

1. Have a GitLab project at a nested path: gitlab.com/conbo_harbour/apps/storybook/storybook.components
2. Go to npmjs.com → package → Settings → Trusted Publishers → Add GitLab CI/CD
3. Enter conbo_harbour as Namespace and apps/storybook/storybook.components as Project (this seems logical —
   top-level group as namespace, rest as project path)
4. The UI accepts this without any warning
5. Run npm publish --provenance from GitLab CI with a valid NPM_ID_TOKEN

Expected Behavior

Either:

• The UI should validate or hint that namespace must be the full group path including subgroups (i.e.,
  conbo_harbour/apps/storybook) and project must be only the project name (storybook.components)
• Or the documentation should clearly explain this with a subgroup example

Actual Behavior

npm publish fails with:

POST 404 https://registry.npmjs.org/-/npm/v1/oidc/token/exchange/package/@conboai%2fstorybook.components
OIDC token exchange error - package not found
npm error code ENEEDAUTH

This is because GitLab's OIDC token contains namespace_path: conbo_harbour/apps/storybook, which doesn't match
the configured namespace conbo_harbour.

Correct Configuration

For a project at gitlab.com/conbo_harbour/apps/storybook/storybook.components:

  ┌───────────┬──────────────────────────────┐
  │   Field   │        Correct value         │
  ├───────────┼──────────────────────────────┤
  │ Namespace │ conbo_harbour/apps/storybook │
  ├───────────┼──────────────────────────────┤
  │ Project   │ storybook.components         │
  └───────────┴──────────────────────────────┘

Suggestions

1. Update the Namespace field description from "Your GitLab username or group name" to "Your full GitLab group
   path, including subgroups (e.g., my-org/team/sub-team)"
2. Add a nested subgroup example to the https://docs.npmjs.com/trusted-publishers/
3. Ideally, validate the namespace/project combination against GitLab's OIDC claim format before saving

Environment

• GitLab.com shared runners
• GitLab project path: conbo_harbour/apps/storybook/storybook.components

[gecube]

Additional: Dynamic/child pipelines

Our publish job doesn't run directly from .gitlab-ci.yml. Instead:

1. .gitlab-ci.yml triggers a create-file-job that runs a Python script
2. The Python script generates dynamic-pipeline.yml as an artifact
3. A trigger job launches a child pipeline from that artifact
4. The child pipeline's npm_build job does the actual npm publish

  # .gitlab-ci.yml (parent)
  trigger-dynamic-pipeline:
    stage: trigger
    trigger:
      include:
      - artifact: dynamic-pipeline.yml
        job: create-file-job

GitLab's OIDC token includes a ci_config_ref_uri claim, which for child pipelines is either null or references
the parent .gitlab-ci.yml, not the generated YAML.

Questions that the docs don't answer:

• What should "Top-level CI file path" be set to when the publishing job runs in a dynamically generated child
  pipeline?
• Does npm validate the ci_config_ref_uri claim? If so, does null cause a mismatch?
• Should it be .gitlab-ci.yml (the parent), dynamic-pipeline.yml (the generated child), or left empty?

This is a common CI pattern (generate pipeline config based on runtime conditions) and should be documented.