Skip to content

Latest commit

 

History

History
145 lines (92 loc) · 9.05 KB

CONTRIBUTING.md

File metadata and controls

145 lines (92 loc) · 9.05 KB
Raw

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 [email protected]. 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 9.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 9.0

  • Build the 9.0 Ubuntu Noble images using version and OS arguments. Note that this will not build noble-chiseled images as those are labeled by a different OS in manifest.json.

    > ./build-and-test.ps1 -Version 9.0 -OS noble -Mode Build

  • Build the 9.0 Ubuntu Noble images using Dockerfile paths. This will will build noble-chiseled images as those Dockerfiles will match the noble part of the Paths argument.

    > ./build-and-test.ps1 -Paths '*9.0*noble*' -Mode Build

  • Build and test the samples

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

  • Test the 9.0 Nano Server 1809 images (remember to switch to Windows container mode in Docker Desktop)

    > ./build-and-test.ps1 -Version 9.0 -OS nanoserver-1809 -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 9.0 product versions (uses a helper script for running update-dependencies)

    > ./eng/Set-DotnetVersions.ps1 -ProductVersion 9.0 -SdkVersion 9.0.100 -RuntimeVersion 9.0.0 -AspnetVersion 9.0.0

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

    > ./eng/Set-DotnetVersions.ps1 -ProductVersion 8.0 -MonitorVersion 8.0.5

  • Update the PowerShell version used in the 9.0 images

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

Checking Markdown links locally

This repo uses UmbrellaDocs/linkspector to automatically validate links in markdown files. You can run this tool locally using Docker.

  1. Build linkspector Docker image: docker build --no-cache --pull --build-arg LINKSPECTOR_PACKAGE= -t umbrelladocs/linkspector https://github.com/UmbrellaDocs/linkspector.git
  2. Run linkspector: docker run --rm -it -v ${PWD}:/app umbrelladocs/linkspector bash -c 'linkspector check -c /app/.github/linters/.linkspector.yml'