dotnet-docker/CONTRIBUTING.md

Contributing

See dotnet/runtime Contributing for information about coding styles, source structure, making pull requests, and more.

General Feedback and Questions

Please open a discussion.

Reporting Security Issues

Please keep in mind that the GitHub issue tracker is intended for reporting non-security bugs and feature requests.

If you're reporting the presence of a disclosed security vulnerability, such as a CVE reported in one of our container images, please follow our documented guidance on vulnerability reporting.

If you believe you have an issue that affects the security of .NET, please do NOT create an issue and instead email your issue details to secure@microsoft.com. Your report may be eligible for our bug bounty, but ONLY if it is reported through email.

Bugs and Feature Requests

Before reporting a new issue, try to find an existing issue if one already exists. If it already exists, please upvote it (👍) or add a comment to the issue with your unique scenario and requirements. Upvotes and clear details on the issue's impact help us prioritize issues to work on. If you can't find an existing issue, file a new one - we would rather get duplicate feedback than none.

We aspire to respond to all GitHub issues within 48 hours (first contact). We triage issues and decide which issues to prioritize on a weekly basis, so if you don't receive a reply within a week or two, please feel free to add another reply to your own issue or mention the @dotnet/dotnet-docker-reviewers team.

How to Submit a PR

Before you write code...

Please consider opening a feature request. We are happy to accept community contributions - however, until we discuss your specifc ideas and features as a team, we can't guarantee that we will accept all community PRs. The last thing we want is for you to spend time on an implementation before the team and community agree on the proposed change. Once the community and the .NET team are in agreement on a proposal, we are happy to work on the feature ourselves. However, if you'd still like to implement it yourself, you can request the issue be assigned to you.

Branches

When making PRs, all source code changes (e.g. Dockerfiles, tests, and infrastructure) should be made in the nightly branch. Only changes to the samples and documentation will be accepted against the main branch.

Workflow Instructions

Building

The build-and-test.ps1 script will build and test the .NET Docker images. Given the matrix of supported .NET versions, distros, and architectures there are numerous Dockerfiles and building can take a while. To make this manageable, the script supports several options for filtering down what images get built and tested.

• Build and test all of the .NET 8.0 images for the Docker platform your machine is targeting (e.g. linux/x64, linux/arm, linux/arm64, windows/x64).

  > ./build-and-test.ps1 -Version 8.0
  

• Build the 8.0 Nano Server 1809 images

  > ./build-and-test.ps1 -Version 8.0 -OS nanoserver-1809 -Mode Build
  

• Build and test the samples

  > ./build-and-test.ps1 -Path *samples* -TestCategories sample
  

• Test the 8.0 Ubuntu Jammy images for the current architecture (e.g. x64, arm, arm64).

  > ./build-and-test.ps1 -Version 8.0 -OS jammy -Mode Test
  

Editing Dockerfiles

The Dockerfiles contained in this repo are generated from a set of Cottle based templates. A single template generates the set of Dockerfiles that are similar (e.g. all Windows sdk Dockerfiles for a particular .NET version). This ensures consistency across the various Dockerfiles and eases the burden of making changes to the Dockerfiles. Instead of editing the Dockerfiles directly, the templates should be updated and then the Dockerfiles should get regenerated by running the generate Dockerfiles script.

Editing READMEs

The READMEs contained in this repo are used as the descriptions for the Docker repositories the images are published to. Just like the Dockerfiles, the READMEs are generated from a set of Cottle based templates. This ensures consistency across the various READMEs and eases the burden of making changes. Instead of editing the READMEs directly, the templates should be updated and then the READMEs should get regenerated by running the generate READMEs script.

Tests

There are two basic types of tests for each of the images produced from this repo.

1. Unit tests that validate the static state of images. This includes things like verifing which environment variables are defined.
2. Scenario tests that validate basic usage scenarios. For example the SDK image is used to create, build and run a new console app.

When editing Dockerfiles, please ensure the appropriate test changes are also made.

Metadata Changes

The manifest.json contains metadata used by the engineering infrastructure to build and publish the images. It includes information such as:

• Dockerfiles to build
• Image Tags
• Manifest/shared tags to create and which images they reference
• Docker repositories to publish the images to
• Dockerfile templates used to generate the Dockerfiles
• etc.

When adding or removing Dockerfiles, it is important to update the manifest.json accordingly.

Updating Product Versions

Updating the product versions (e.g. .NET runtime, ASP.NET runtime, PowerShell, etc.) contained within the images is typically performed by automation. All of the product version information is stored in the manifest.versions.json file. The Dockerfile templates reference the product versions numbers and checksums from this file. Updating a product version involves updating the manifest.versions.json and regenerating the Dockerfiles. If there are cases where you need to update a product version, you can use the update-dependencies tool. The tool will do the following:

1. Update the product versions and checksums stored in manifest.versions.json
2. Regenerate the Dockerfiles
3. Update the tags listing in the readmes

The following examples illustrate how to run update-dependencies:

• Update the 8.0 product versions (uses a helper script for running update-dependencies)

  > ./eng/Set-DotnetVersions.ps1 -ProductVersion 8.0 -SdkVersion 8.0.100 -RuntimeVersion 8.0.0 -AspnetVersion 8.0.0
  

• Update the .NET Monitor version (uses a helper script for running update-dependencies)

  > ./eng/Set-DotnetVersions.ps1 -ProductVersion 6.3 -MonitorVersion 6.3.1
  

• Update the PowerShell version used in the 8.0 images

  > dotnet run --project .\eng\update-dependencies\ -- 8.0 --product-version powershell=7.2.7 --compute-shas