Find files, editable templates and browser test targets by what you need to make or test. Explore complete business kits for connected records, templates and expected results.
Page 90 of 221; 24 results per page.
A deprecated-syntax workflow: ::set-output, ::set-env and ::add-path markers, a retired runner label, and v2 action pins. Every construct here was removed from the runner, so an upgrade migrator can be scored on whether it rewrites all of them.
An expression-dense workflow: fromJSON-generated matrix axes, hashFiles cache keys, format and join calls, a folded multi-line if condition, and the && / || coalescing idiom that stands in for a ternary. For testing template resolvers before any schema check.
The matrix case that expanders get wrong: a 3x3 base grid, two exclude rules, and one include entry that adds a combination and an extra key. Nine minus two plus one is eight jobs, documented in the specs so an expansion can be scored exactly.
A GitHub Actions CI workflow with a two-axis build matrix (three Node versions across two runners), an npm cache, and a conditional artifact upload. Six matrix combinations, so a workflow linter or matrix expander has a documented answer to check against.
The workflow file that exposes the YAML 1.1 boolean resolver: a bare `on` key becomes True in PyYAML, SnakeYAML and Psych, so a round-trip through those loaders loses the trigger block. The env values repeat the trap with NO, yes and off alongside a quoted control.
A schema-valid workflow that should still be rejected on review: permissions: write-all at the workflow level plus three unused write scopes on the job. Nothing here is an exploit; it is the least-privilege finding a policy engine is supposed to raise.
The called half of a reusable-workflow pair: a workflow_call trigger with typed inputs, a default value, and a declared output wired to a job output. Pair it with the caller fixture to test cross-workflow input and output resolution.
The calling half of a reusable-workflow pair: a workflow_dispatch trigger with a choice input, two jobs that call the same reusable workflow with different arguments, and a third that consumes their outputs through needs.
A scheduled workflow with two cron entries plus a manual workflow_dispatch trigger carrying a boolean and a choice input. For testing cron parsers, trigger extraction, and input-type handling in workflow tooling.
An intentionally invalid GitHub Actions workflow: well-formed YAML that breaks the workflow schema in four documented ways, no jobs mapping, a scalar `on`, a mapping `runs-on`, and a step carrying both uses and run. For testing that a validator rejects, and reports why.
Every escape the format defines, including the one nobody expects: a trailing space is stripped from a pattern unless it is backslash-escaped, so `draft\ ` and `draft` ignore different files. Editors that trim trailing whitespace on save silently change what this file means.
One pattern per rule in the gitignore grammar: a leading slash that anchors to the containing directory, the same name unanchored, `**` in all three positions, `?` and `[...]` classes, and a trailing slash that matches only directories. Every line is a separate assertion for a matcher's test suite.
The single most misunderstood rule in the format: once `build/` excludes a directory, git does not descend into it, so `!build/keep.txt` is dead. The file is valid and the behaviour is documented: it is the author's expectation that is wrong, which is exactly why an ignore-matcher must reproduce it rather than being helpful.
A realistic monorepo ignore file that uses `dist/*` rather than `dist/` precisely so the two `!dist/...` re-inclusions below it can work. It also carries the `.env.*` / `!.env.example` and `*.log` / `!logs/retained/*.log` pairs that every ignore-matcher has to order correctly.
The corrected twin: `build/*` excludes the directory's contents instead of the directory, so git still descends and `!build/keep.txt` re-includes the file. The two fixtures differ by two characters and produce opposite results, which makes them a precise pass/fail pair for an ignore engine.
GitLab's `!reference` custom YAML tag used three ways: inside a script list, as a whole after_script value, and as a whole rules value. A stock YAML 1.2 loader has no constructor for it and raises; GitLab's loader resolves each key path.
The two GitLab inheritance mechanisms in one file: YAML anchors with merge keys, which the loader resolves before GitLab sees the document, and `extends`, which GitLab resolves afterwards with a deep merge. Hidden .job keys carry both.
Dynamic child pipelines and a cross-project downstream trigger: one job generates a pipeline file as an artifact and a trigger job includes it, while a second trigger job starts a downstream project's pipeline with strategy: depend.
An intentionally invalid GitLab CI config: valid YAML with a misspelled `stagess` key, a job naming an undeclared stage, a job with no script, and an `only:` given a bare scalar. For testing that a linter rejects it and names each fault.
A deprecated-syntax GitLab CI file using `only`/`except` in both the array and keyed forms, plus the long-retired `type:` keyword. For scoring a migrator that must rewrite all of it to `rules` and `stage`.
Five include entries across the four include kinds: local path, local glob, another project at a pinned ref, a remote URL, and a bundled template. For testing include resolvers and dependency graphing without any file actually being fetched.
Both GitLab parallelisation forms in one file: a plain `parallel: 4` shard split and a `parallel: matrix` block whose two entries expand to seven combinations. Eleven jobs in total, documented so an expander can be checked exactly.
Rule-driven GitLab CI: a workflow block with four ordered conditions ending in `when: never`, plus job rules combining changes patterns, regex tag matching, a null-branch comparison, and a manual allow-failure fallback.
A three-stage GitLab CI pipeline with a default block, global variables, artifact expiry, a needs-based DAG, and a coverage-extraction regex. The baseline the other GitLab fixtures vary from.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
