Documentation
¶
Overview ¶
Package pipelines builds ir.NormalizedPipeline values from CI files for tests, so the controls' tests, the situation tests and the control package's corpus share one reading of the YAML instead of three copies.
Two readings are offered. GitHubFromFiles and GitLabFromFiles go through the production collectors (github's workflow scan, gitlab's ToNormalizedPipeline over a merged configuration), offline: no action metadata, no project settings, nothing fetched (GitHubFromFiles sets the GitHub offline switch for the test, since the workflow scan reads action definitions even without the metadata enrichment). ParseGitHubWorkflow and ParseGitLabCI are the narrow test-time parsers the rule tests were written against, which read only the fields those tests need.
Nothing outside tests imports this package.
Index ¶
- func GitHubFromFiles(t testing.TB, files []string) *ir.NormalizedPipeline
- func GitLabFromFiles(t testing.TB, files []string) *ir.NormalizedPipeline
- func ParseGitHubWorkflow(t *testing.T, data []byte, originFile string) *ir.NormalizedPipeline
- func ParseGitLabCI(t *testing.T, data []byte) *ir.NormalizedPipeline
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func GitHubFromFiles ¶
func GitHubFromFiles(t testing.TB, files []string) *ir.NormalizedPipeline
GitHubFromFiles copies the given workflow files into a scratch .github/workflows directory and scans it with the production collector, without action metadata enrichment and with the offline switch (github.EnvDisableGitHubAPI) set for the test: the nested actions stage reads action definitions whatever the enrichment says, so the switch is what keeps the scan off the network. The closure is therefore unresolved (R6) and the pipeline holds the workflows' direct references only. A parallel test cannot call t.Setenv, so its parent sets the switch before the parallel subtests start (control/corpus_test.go does) and GitHubFromFiles leaves an already set switch alone. Job names come out namespaced by workflow file base name ("release/publish"), as in a real run. A file the collector cannot read or parse fails the test.
func GitLabFromFiles ¶
func GitLabFromFiles(t testing.TB, files []string) *ir.NormalizedPipeline
GitLabFromFiles reads one file as the project's merged CI configuration (what GitLab's lint endpoint returns as merged_yaml: includes inlined, extends resolved) and projects it through gitlab.ToNormalizedPipeline, the function a real run calls. Every top-level mapping that is not a reserved keyword becomes a job, as the collector's job map does, and every job counts as declared in the project's own file. Branch protection, settings variables and visibility are left for the caller to set from recorded facts.
func ParseGitHubWorkflow ¶
ParseGitHubWorkflow is the GitHub counterpart of ParseGitLabCI: workflow `on:` triggers and push filters propagated to every job, workflow and job permissions, the merged env, job-level `if:`, `container:`, step `uses:` with their `with:` maps, `run:` bodies, the artifacts derived from upload/download steps, `environment:`, `needs:` and `secrets: inherit`. originFile is set on every job, as the collector sets the workflow file path, so a test can merge several fixture files into one pipeline and still tell them apart. Job names stay bare (the collector namespaces them by workflow file; GitHubFromFiles is that reading).
func ParseGitLabCI ¶
func ParseGitLabCI(t *testing.T, data []byte) *ir.NormalizedPipeline
ParseGitLabCI is a deliberately narrow parser that extracts what the rule and situation tests read: jobs with their image, services, variables, allow_failure, when, script, rules and only/except. It is the test-time substitute for the full collector, which depends on the GitLab API. Limitations: no include/extend resolution, no default propagation, no variable expansion. Extend as new rules require it; GitLabFromFiles is the production reading when a test needs everything.
Types ¶
This section is empty.
Source Files