build-common

Common build targets and scripts necessary for libraries and components

What's included

1. Common.props file necessary to be included from your root Directory.Build.props

2. Shared .target files in targets/ directory. Includes NullableEnable, TrimmingEnable, SignEnable, PackEnable and more.

   These targets can be referenced with $(RepositoryTargetsRoot) prefix

   <Import Project="$(RepositoryTargetsRoot)/NullableEnable.targets" />

3. Nuke extension, including BuildToLocalCache and simple obfuscation/ilmerge wrappers

4. Avalonia strong name key and public key

5. Some branding images, like default nuget package icon

6. Reusable GitHub Actions workflows under .github/workflows/:

   • library-cicd.yml — build, test, pack, push, and optionally GitHub-release a library.
   • source-release.yml — package a customer-facing source zip when a library is released. See scripts/source-release/stage.sh.

Source-release workflow

Drop the following into .github/workflows/source-release.yml in any consumer repository to wire up source-zip packaging on release publish:

name: Source Release

on:
    release:
        types: [published]
    workflow_dispatch:
        inputs:
            ref:
                description: 'Commitish (branch, tag, or SHA) to package. Leave empty to use the dispatched branch.'
                required: false
                default: ''
            version:
                description: 'Version for the zip (no leading v).'
                required: true
                default: 0.0.0-test1
            upload_to_s3:
                description: 'Upload the zip to S3.'
                required: false
                type: boolean
                default: false

concurrency:
    group: source-release-${{ github.event.release.tag_name || inputs.version }}
    cancel-in-progress: false

jobs:
    source-release:
        # Pin to a specific commit SHA (not a branch or tag) — any move of
        # @main would otherwise immediately affect every consumer. Look up
        # the latest source-release SHA from this repo's commit history and
        # bump intentionally. Dependabot's `github-actions` ecosystem can
        # automate this.
        uses: AvaloniaUI/build-common/.github/workflows/source-release.yml@<sha>
        with:
            project_name: Avalonia.Controls.Example
            ref: ${{ inputs.ref }}                               # empty on release events
            version: ${{ inputs.version }}                       # empty on release events
            upload_to_s3: ${{ github.event_name == 'release' || inputs.upload_to_s3 }}
            # allow_list: .github/source-release/projects.txt    # default
            # solution_file: Avalonia.Controls.Example.slnx       # required only if multiple .slnx exist at the repo root
        secrets:
            checkout_token: ${{ secrets.SUBMODULE_TOKEN }}
            license_key: ${{ secrets.ACCELERATE_LICENSE_KEY }}
            aws_access_key_id: ${{ secrets.COMP_SOURCE_WRITE_SCW_ACCESS_KEY }}
            aws_secret_access_key: ${{ secrets.COMP_SOURCE_WRITE_SCW_SECRET_KEY }}
            aws_region: fr-par
            s3_bucket_endpoint: ${{ vars.COMP_SOURCE_BUCKET_ENDPOINT }}

The workflow_dispatch trigger lets you exercise the full pipeline (stage → scan → zip → verify-build) on demand without publishing a release, and can also repackage historic releases by setting ref to the relevant tag or commit SHA together with the matching version. The upload_to_s3 checkbox controls whether the resulting zip is shipped to S3 — leave it off for test runs and enable it when intentionally re-publishing a historic version. Release events always upload regardless.

The caller repository must:

• Include build-common as a submodule at the repository root, pinned to a commit that contains scripts/source-release/stage.sh.
• Provide an allow-list of customer-facing csproj paths at the configured path (default .github/source-release/projects.txt).
• Have a *.slnx file at the repository root. The staging script reads it to know the original solution filename and reuses it for the customer- facing slnx so build instructions don't change. If multiple .slnx files exist at the root, set the solution_file input to disambiguate; otherwise the first one in filesystem order is picked. .sln is not currently supported.

The reusable workflow and stage.sh rely on Linux tooling — GNU readlink, jq, zip/unzip, the AWS CLI — and only run on ubuntu-latest.