Skip to content

ci-cd.md

Latest commit

 

History

History
112 lines (75 loc) · 4.87 KB

ci-cd.md

File metadata and controls

112 lines (75 loc) · 4.87 KB
Raw

CI/CD

FindRomCover uses GitHub Actions for continuous integration, documentation publishing, and releases. Three workflows live in .github/workflows.

CI — build and test

ci.yml runs on every push to master, every pull request targeting master, and manually via workflow_dispatch.

Step Detail
Runner windows-latest
SDK .NET 10.0.x
Restore dotnet restore CSharp_FindRomCover.sln
Build dotnet build --configuration Release --no-restore
Test dotnet test --configuration Release --no-build --verbosity normal

Concurrency is configured with cancel-in-progress, so a new push cancels an in-progress run for the same branch.

Docs — GitHub Pages and wiki

docs.yml publishes the documentation site and synchronizes the GitHub wiki. It runs on pushes to master that touch any of these paths, and can be triggered manually:

  • docs/**
  • mkdocs.yml
  • scripts/Sync-Wiki.ps1
  • .github/workflows/docs.yml

GitHub Pages job

  1. Checks out the repository and installs Python 3.13.
  2. Installs MkDocs Material from docs/requirements.txt.
  3. Builds the site with mkdocs build --strict.
  4. Uploads the site/ artifact.
  5. Deploys it with the official actions/deploy-pages action.

Required repository setting:

  1. Open Settings > Pages.
  2. Set Source to GitHub Actions.

After the first successful run the site is available at:

https://purelogiccode.github.io/FindRomCover/

The left-hand navigation is generated from the nav section of mkdocs.yml.

Wiki job

  1. Checks whether the WIKI_TOKEN secret is configured; if not, the job stops with a clear message instead of failing.
  2. Runs scripts/Sync-Wiki.ps1, which converts docs/ into wiki pages.
  3. Clones <owner>/<repo>.wiki.git using the token.
  4. Copies the generated pages, _Sidebar.md, and _Footer.md into the wiki repository.
  5. Commits and pushes only when something changed.

The sidebar is generated by the same script, so the wiki gets the same section-based side menu as the site.

One-time wiki setup

  1. Open the repository's Wiki tab and create the first page (for example Home). GitHub only creates the wiki Git repository after the first page exists.
  2. Create a fine-grained personal access token or a classic token with the repo scope that can push to the wiki.
  3. Add it as an Actions secret named WIKI_TOKEN under Settings > Secrets and variables > Actions.

Note: The default GITHUB_TOKEN cannot push to wiki repositories, which is why a personal access token is required.

Manual wiki sync

pwsh ./scripts/Sync-Wiki.ps1 -OutputPath wiki-out

Then copy the contents of wiki-out into a clone of the wiki repository and push.

Release process

Releases are produced automatically by release.yml, which runs when a tag named release_* (for example release_3.3.0) is pushed:

  1. Update the version in FindRomCover/FindRomCover.csproj (Version, AssemblyVersion, and FileVersion) and in FindRomCover.Tests/FindRomCover.Tests.csproj (AssemblyVersion and FileVersion) — keep both in sync.

  2. Update README.md, WhatsNew.md, and docs/release-notes.md.

  3. Build and test locally, then push to master and confirm CI is green. This push also redeploys the documentation site and the wiki through docs.yml.

  4. Create and push the tag:

    git tag release_3.3.0
git push origin release_3.3.0

  5. release.yml builds five framework-dependent single-file bundles and creates the GitHub release with them attached:

    Runner Bundles
    windows-latest release_<version>_win-x64.zip, release_<version>_win-arm64.zip
    ubuntu-latest release_<version>_linux-x64.zip, release_<version>_linux-arm64.zip
    macos-latest release_<version>_osx-arm64.zip

    There is no Intel-Mac (osx-x64) bundle because Magick.NET 15 no longer ships a macOS x64 native library.

    Each archive contains the published application plus LICENSE.txt, README.md, and WhatsNew.md. The release notes link to the full changelog in WhatsNew.md at the tagged commit.

  6. The in-app update checker picks up the new release automatically: it reads the latest release's tag_name from the GitHub API and parses the version after the release_ prefix, so tags must keep the release_<major>.<minor>.<patch> format.

Note: The release job needs contents: write permission (already declared in release.yml) to create the GitHub release. No extra secrets are required.

Versioning

Versions follow a major.minor.patch scheme. Tags use the release_ prefix (for example release_3.3.0). The application version lives in the project file, and the documentation release notes mirror the GitHub releases.

Related pages