feat(parser): add pipeline parser and CLI commands

[nahallacman]

Summary

• What changed and why?
• Link related issue(s): Fixes #

Change Type

• feat
• fix
• refactor
• docs
• test
• chore

Context

User-facing impact

• What behavior changes for users?

GitLab scope

• gitlab.com
• self-managed GitLab
• both

Affected areas

• Component Browser
• Hover provider
• Completion provider
• Validation provider
• Cache and refresh behavior
• GitLab API calls/auth/token storage
• Docs only

Validation

Local checks

• npm run compile
• npm test or targeted tests
• Manual verification in VS Code Extension Host

Manual test notes

• Include exact scenario(s), sample .gitlab-ci.yml, and observed results.

Breaking Changes

• No breaking changes
• Breaking changes (describe below)

If breaking changes exist, describe migration steps:

Screenshots / Recordings (if UI behavior changed)

• Add before/after visuals for Component Browser, hover, completion, or validation changes.

Risk and Rollback

• Main risks:
• Rollback strategy:

Release Notes Draft

• One short line suitable for CHANGELOG/release notes.

Checklist

• Branch is up to date with target branch
• Commit messages follow conventional commits
• Added/updated docs for behavior or settings changes
• Added/updated tests for new behavior
• No secrets or tokens in code, logs, screenshots, or test fixtures

[eFAILution]

Thanks for splitting the parser out into its own PR, @nahallacman. Before we go deep on review, there's one question that shapes the whole design of the PEP piece — and you're far better placed to answer it than we are, since you've got a project with a pipeline execution policy actually applied.

The question: does GitLab's CI Lint API, in dry_run mode, already include the policy-injected (PEP) jobs in its simulated pipeline?

Why it matters for this PR: POST /projects/:id/ci/lint with dry_run: true simulates pipeline creation for a ref without pushing — it resolves include:s and rules and returns the merged YAML plus the jobs that would run. What the docs don't say is whether that simulation also runs the security-policy merge that injects PEP jobs. So:

• If it does → the extension could call this endpoint and let GitLab resolve everything authoritatively (including the policy), rather than re-deriving the pipeline locally — which would make most of the hand-rolled parser redundant.
• If it doesn't → your local PEP-file merge is filling a real gap GitLab's own tooling can't cover, and the strongest design is probably dry_run for the base pipeline + the local policy merge layered on top.

Could you run this against a PEP-applied project and paste the jobs array (and merged_yaml)? Easiest is to let jq handle the YAML→JSON escaping:

jq -Rs '{content: ., dry_run: true, include_jobs: true, dry_run_ref: "main"}' .gitlab-ci.yml \
| curl --silent --request POST \
    --header "PRIVATE-TOKEN: $TOKEN" \
    --header "Content-Type: application/json" --data @- \
    "https://<your-gitlab-host>/api/v4/projects/<project-id>/ci/lint" | jq .

(content is the raw .gitlab-ci.yml; dry_run_ref is the branch whose rules/context to simulate; the token needs api scope.) GitLab adds no "from policy" marker on injected jobs, so you'd spot the PEP jobs by your policy's known job-name prefix — or by any job in the response that isn't in your own config.

That result will steer the rest of the review (and tell us how much of the local resolver we actually need). Thanks!