v0.11.0

Added

• Added shell auto-completion support through the completion command.

Fixed

• prepare no longer describes one version twice. A version whose packages had shipped in part was read as one that had never shipped at all, so prepare staged it a second time.
• Notes written after a prepare join the entry they belong to. Preparing a version the changelog already has an entry for now adds the unreleased notes to that entry rather than giving the version a second heading.

v0.10.0

Added

• The tool client works the way the SDK does. IDotNet's tool methods are one per dotnet tool verb — ToolInstall, ToolUpdate, ToolUninstall, and InstalledToolVersion for list.
• The engine reads and writes project files. IProjectFiles and ProjectFile load a ritten.json as a document, set values by key path, and write it back with everything else intact.
• Ritten.GitHub maintains GitHub Actions workflows. IActionsWorkflows and ActionsWorkflow read a workflow file, find its jobs by what they run, and write a job or a trigger back into it without disturbing a line of the rest.
• Ritten.DotNet manages the tool manifest. IDotNet gains ToolUpdate and CreateToolManifest, and DotNetProjects reads what a repository holds.
• Jobs can declare that they run without a project. IJob.RequiresProject is what lets a job create the project file.
• Workflows can check compatibility. IWorkflow.IsCompatible answers whether a directory looks like its kind, and WorkflowRegistry.IsCompatible asks each in registration order.
• A file knows its directory, and a directory can place one. IFile.Directory returns the directory a file is in, so anything writing a nested file can create the path first, and IDirectory.RelativePath(file)/RelativePath(directory) write a path the way a project file spells one.

Changed

• ritten init is now a job instead of a command. It runs like every other job, with --dry-run, --verbose and the rest, and each workflow declares its own. A repository with no ritten.json yet has its workflow detected by what's in it, or --workflow sets one explicitly.
• Resolving a repository is its own step. WorkflowApplication.SelectWorkflow detects the workflow for a given directory.
• Workflows can run without a project file. RittenProject.Resolve answers with a synthetic project when nothing has been written yet.
• Init ensures rather than scaffolds. Every file it touches is loaded as a document, given whatever it's missing, and written back, so a changelog keeps its entries, a ritten.json keeps all its keys, a tool manifest keeps the other tools it pins, and an Actions workflow keeps its other jobs, triggers, and comments.
• The Actions workflow is named for the project, and found by what it runs. Ritten owns the jobs it wrote, not the file they live in: a renamed workflow file is updated in place rather than duplicated.

v0.9.0

Added

• The report is written to a file. Every run now leaves its report at artifacts/report.md, so the best thing a run produces is no longer readable only on GitHub Actions.
• ritten init sets a repository up. It writes the four files a repository needs — ritten.json, CHANGELOG.md, the tool manifest, and the GitHub Actions workflow. --check reports what's missing or has drifted, --verbose shows what a drifted file should say, and --force rewrites the files Ritten generates.
• Jobs declare what they're for. JobKind classifies a job the way StepKind classifies a step — Work, Check, or Deploy.
• PhysicalFile and PhysicalDirectory are public. IFile and IDirectory were public with no way for anything outside the engine to produce one, so a module holding a real path had nothing to hand back.
• Steps can reach the repository root. IGit.RepositoryRoot() returns the root of the repository the workflow is running in, which isn't always the project root.

Fixed

• The pending comment links to the run logs. Just the same as the completed report comment.
• Output lines up outside a run. A step's body is indented under its heading, which left a command that runs no steps reporting at two different levels for no reason.

v0.8.0

Added

• ritten prepare stages the next release. It gives the unreleased notes a version heading, brings the changelog's version links up to date, updates the project version, and formats the code. The version is derived from the unreleased notes and confirmed before anything is written; use --version to name one explicitly.
• Jobs can now take arguments. A job's Arguments name what it needs to run. The job reads them in Configure and registers the domain values its steps consume, so steps never see a command line and stay reusable.
• The command line ships as a package. Ritten.CommandLine renders a System.CommandLine surface from the registered model: commands are the jobs of whichever workflow the repository declares, carrying each job's Description and an option per argument it takes. A host wires it up in a line — `await command.InstallRitten(application).
• Changelogs can be written, not just read. IChangelog.Write and Render join the client's read half, with a dry-run pairing so a rehearsal narrates the file it would write instead of writing it.

Changed

• --force belongs to the job that honors it. It was a global flag that every job accepted and only install read. It's now an argument install declares, so it appears exactly where it means something.
• Changelog and ChangelogEntry are records. Preparing a release is a change to one entry of an otherwise untouched document, which wants with.

v0.7.0

Added

• Tools install from source. The dotnet-tool workflow gains an install job: it builds, packs, and installs the tool globally from the working tree, so no feed is needed to try a build. A version that's already installed stops the job early; --force reinstalls it.
• Package metadata is checked. check and deploy now fail when a shipped package is missing a description, readme, or license — the gaps NuGet only warns about after the push.
• Report sections share a vocabulary. SectionName is a value object for the sections of the workflow report.

Fixed

• Every package carries the readme. The engine and domain packages now pack the repository readme, so their NuGet pages aren't bare.

v0.6.0

Changed

• Commands show their output. A command's output now prints by default, so long-running tools like dotnet test narrate themselves the way they do outside Ritten.
• AddGit() needs no tag prefix. The prefix configures the tagging steps, not the client, so a host that never tags adds the client alone.

v0.5.0

Added

• Git can read files and changes. IGit gains Show (a file's content as it exists at a reference) and ChangedFiles (the paths that differ from the committed state, untracked files included), so checks can compare against a base branch through the same client that tags.

v0.4.0

Added

• GitHub ships as a package. The GitHub Actions runtime now ship as Ritten.GitHub.
• Git and .NET ship as packages. Ritten.Git and Ritten.DotNet carry their own tech-specific stuff.
• The engine runs external commands. The Ritten.Commands module moved from the CLI into Ritten.Core.
• Steps can read the pull request under review. The engine owns a PullRequest contract (number, base ref) and an IPullRequestLabels read returning Label values (name, color, description), and the active runtime supplies them — GitHub Actions fills both from its own claims and the GitHub API. Where nothing can answer — a local run, a runtime without the concept — labels read as null, distinct from a pull request that simply carries none, and a host can always register its own implementation to take precedence.

Changed

• IBuildReport is now IWorkflowReport. It more accurately reflects that the report covers one workflow execution.
• Run context is injected directly. RunContext (and the new PullRequest) are immutable records that steps and services take by type, no longer configured or consumed through IOptions.
• Exit codes are value objects. ExitCode replaces the bare int (and the WorkflowExitCodes constants, which now live on it as ExitCode.Success and friends). It converts implicitly to and from int at the process boundaries.
• Result sinks are called on start and finish. IWorkflowResultSink (was IReportSink) can announce the run when it starts with a pending pull request comment, and publishes a single artifact.
• MarkdownReportRenderer is public. And now takes the Report whole, for any sinks that want to render in Markdown.

v0.3.0

Changed

• Separate Ritten.Core package. With this release, Ritten.Core is now published for direct consumption in building custom CI workflows.

v0.2.0

Added

• The Core is a separate project. Ritten.Core now lives in a separate project. In a future release, it will be consumable directly.
• A repository can ship several packages. build.projects lists every project to pack and publish (single-target projects keep using build.project). Packages release in lockstep, with one key version, one changelog entry, and one tag. The first project is used as the metadata source.
• Decorators are builder-level now. Service decorators and replacements for dry runs can now be registered directly on the builder using builder.Decorators.
• The project file is the host's to name. An application built on the engine can point at its own file (builder.ProjectFileName = "build.json"), and every error message names that file, so embedding Ritten never has to be announced in the repository.