Adding a New Deployable Project

When a new .csproj is added to Gondwana.sln and should be included in NuGet deployments, update the following files.

Required — CI pipeline

.github/workflows/ci-master.yml

1. "Publish projects needed for staged binaries" step — add a mkdir -p publish/<ProjectName> line and a corresponding dotnet publish line.
2. "Stage exact downloadable binaries" step — add a cp publish/<ProjectName>/<ProjectName>.dll artifacts/ line, or use cp -r / .exe for apps and tools.

.github/workflows/release.yml

1. "Publish projects" step — same pattern: add mkdir -p publish/<ProjectName> and dotnet publish.
2. "Stage release assets" step — add the matching cp line into release-assets/.

Note for apps/tools
For apps/tools such as WinForms executables, use -r win-x64 --self-contained false in dotnet publish and cp -r when staging, so runtime assets are included.

---

Required — PR labels and generated release notes

.github/labeler.yml

Add a label rule so pull requests touching the new project are automatically labeled.

Example:

gondwana-newproject:
  - changed-files:
    - any-glob-to-any-file: 'Gondwana.NewProject/**'

For projects under Tooling/, use the tooling path:

gondwana-newproject:
  - changed-files:
    - any-glob-to-any-file: 'Tooling/Gondwana.NewProject/**'

If the project has a companion hosting package, include both paths under the same label:

gondwana-newproject:
  - changed-files:
    - any-glob-to-any-file:
      - 'Gondwana.NewProject/**'
      - 'Gondwana.NewProject.Hosting/**'

.github/release.yml

Add a changelog category so generated GitHub release notes group pull requests for the new project.

Example:

    - title: Gondwana.NewProject
      labels:
        - gondwana-newproject
        - Gondwana.NewProject

Place the new category near related packages.

For example, a core-adjacent package should go near Gondwana (Core), while a platform adapter should go near the other adapter packages.

Ordering note
Categories are matched in order. If a pull request has both enhancement and gondwana-newproject, it will appear under whichever matching category comes first. Keep the broad change-type categories first if you want release notes grouped by change type; place project categories first if you want them grouped by package.

---

Recommended — changelog grouping

Tooling/scripts/release.ps1 — $ProjectChangelogGroups list

Add a new entry:

[pscustomobject]@{
    Name         = "Your.Project.Name"
    IncludePaths = @("Your/Project/Path/**/*")
}

Example:

[pscustomobject]@{
    Name         = "Gondwana.NewProject"
    IncludePaths = @("Gondwana.NewProject/**/*")
}

Tooling/scripts/Generate-Project-Changelogs.ps1 — $DefaultProjects list

Add the repo-root-relative folder path.

Examples:

"Gondwana.NewProject"

or:

"Tooling/Gondwana.NewProject"

---

Example — Gondwana.Widgets

For Gondwana.Widgets, the expected additions would be:

.github/labeler.yml

gondwana-widgets:
  - changed-files:
    - any-glob-to-any-file: 'Gondwana.Widgets/**'

.github/release.yml

    - title: Gondwana.Widgets
      labels:
        - gondwana-widgets
        - Gondwana.Widgets

Tooling/scripts/release.ps1

[pscustomobject]@{
    Name         = "Gondwana.Widgets"
    IncludePaths = @("Gondwana.Widgets/**/*")
}

Tooling/scripts/Generate-Project-Changelogs.ps1

"Gondwana.Widgets"