paketo-buildpacks/dotnet-core-sdk

.NET Core SDK Cloud Native Buildpack

The .NET Core SDK CNB provides a version of the .NET Core SDK and a version of the .NET Core Driver or the dotnet binary. It also sets the .NET Core SDK on the$DOTNET_ROOT so that it is available to subsequent buildpacks during their build phase and sets the .NET Core Driver on the $PATH so that is available to subsequent buildpacks and in the final running container.

Integration

The .NET Core SDK CNB provides the dotnet-sdk as a dependency. Downstream buildpacks, like .NET Core Build can require the dotnet-sdk dependency by generating a Build Plan TOML file that looks like the following:

[[requires]]

  # The name of the .NET Core SDK dependency is "dotnet-sdk". This value is considered
  # part of the public API for the buildpack and will not change without a plan
  # for deprecation.
  name = "dotnet-sdk"

  # The version of the .NET Core SDK dependency is not required. In the case it
  # is not specified, the buildpack will provide the default version, which can
  # be seen in the buildpack.toml file.
  # If you wish to request a specific version, the buildpack supports
  # specifying a semver constraint in the form of "6.*", "6.0.*", or even
  # "6.0.1".
  version = "6.0.1"

  # The .NET Core SDK buildpack supports some non-required metadata options.
  [requires.metadata]

    # Setting the build flag to true will ensure that the .NET Core SDK
    # depdendency is available in the $DOTNET_ROOT for subsequent buildpacks during
    # their build phase and ensures that the .NET Core Driver dependency is available
    # in the $PATH for subsequent buildpacks. If you are writing a buildpack that needs
    # to use the dotnet sdk & driver during its build process, this flag should be set
    # to true.
    build = true

Usage

To package this buildpack for consumption:

$ ./scripts/package.sh

This builds the buildpack's Go source using GOOS=linux by default. You can supply another value as the first argument to package.sh.

(Deprecated) buildpack.yml Configurations

dotnet-sdk:
  # this allows you to specify a version constaint for the dotnet-sdk dependency
  # any valid semver constaints (e.g. 6.* and 6.0.*) are also acceptable
  version: "6.0.1"

This configuration option will be deprecated with the next major version release of the buildpack. Because the versions of the .NET Core runtime and .NET Core SDK are so tightly coupled, most users should instead use the $BP_DOTNET_FRAMEWORK_VERSION environment variable to specify which version of the .NET Core runtime that the Paketo .NET Core Runtime Buildpack should install. This buildpack will automatically select an SDK version to install that is compatible with the selected .NET Core runtime version.

dotnet-core-sdk's Issues

Conform to RFC RFC0043: Reproducible builds

To conform to RFC0043 this buildpack should ensure that builds are reproducible. Specifically it should not include a built_at metadata field. In the tests that leverage this field to assert layer reuse, we should instead compare layer SHA values across rebuilds.

See also the tracking issue: paketo-buildpacks/rfcs#165.

Consume the SDK dependency from the dep-server

Per paketo-buildpacks/dep-server#45, we should start consuming the .NET Core SDK dependency from the dep-server (https://api.deps.paketo.io/v1/dependency?name=dotnet-sdk and https://deps.paketo.io/dotnet-sdk/...) instead of the https://buildpacks.cloudfoundry.org/dependencies/dotnet-sdk/... location we currently get the dependencies from.

This will make the dependency publishing/consumption process more transparent than the process we use for the dependencies available via the dependency-builds pipeline.

We have already done this switch-over in the Node Engine and Yarn Buildpacks. The outline of what this work will entail can be found in the dep-server issue linked at the top.

Update module from cloudfoundry -> paketo-buildpacks

The current go.mod file references a github.com/cloudfoundry repo. Now that this repo lives in the paketo-buildpacks org, we should update the module name and the internal import statements in this codebase.

Upgrade to buildpack API v0.5

The buildpack currently uses CNB Buildpacks API v0.2. The CNB spec has evolved since then. To take advantage of more upstream features, the buildpack should be upgraded to API v0.5. This will require some implementation changes:

• Store the Bill of Materials in thepackit.BuildMetadata and packit.LaunchMetadata structs, rather than returning it in the packit.BuildPlan. See the Paketo go-dist buildpack for an example.

This migration guide provided by the CNB project explains some relevant changes to the spec.

(other necessary changes TBD)

Prefer configuring SDK version via environment variables over buildpack.yml

Summary

The current implementation allows a buildpack user to choose a .Net Core SDK version using a buildpack.yml configuration file with the following contents:

dotnet-sdk:
  version: 2.1.804

After the approval of RFC0002 we should be preferring to allow that configuration via an environment variable like:

BP_DOTNET_SDK_VERSION="2.1.804"

Deprecation Notice

The buildpack should emit a deprecation notice via log output when a buildpack.yml file appears in the application source code with configuration for this buildpack. The deprecation notice should appear similar to notices that have been implemented in other buildpacks.

Race condition between automated PRs and compatibility table updates

What happened?

Because of the way that compatibility table update commits in this repo are triggered, there seems to be a race condition between these automatic update commits and the review and merge steps of the PR process. If the PR is approved and merged before all compatibility commits are added, the compatibility commits may slip through the cracks. See #324 for an example.

Moreover, if the automation that creates a compatibility commit fails, there's no way to see that this has happened on the PR itself; this makes it easy for maintainers (or automation) to merge a dependency update commit that's missing compatibility updates.

Failure: Create Draft Release workflow

Create Draft Release workflow failed.

Generate SBOM for .NET Core SDK

To implement Paketo RFC0038, this buildpack will need to move from storing SBOM information in layer metadata to storing it in files that the CNB lifecycle can manipulate during the build. The RFC outlines what these files are and what they should contain.

Changes to this buildpack will include:

• Bump to Buildpack API 0.7
• Use packit v2.0.1
• We may need to add a name field to the dotnet-sdk dependency dep-server metadata and the buildpack.toml so that this field is populated in the BOM

refactor: use packit draft package instead of bespoke PlanEntryResolver

This buildpack uses a Plan Entry Resolver to combine build plan entries during the build phase. Paketo's buildpack utility library packit now includes the draft package, which provides the Planner for plan entry resolving.

This buildpack should use the packit Planner in lieu of its one-off plan entry resolver. This will reduce the maintenance overhead for the buildpack.

Add .NET 7 to supported dependencies

Upgrade to packit v2

Please upgrade to the latest packit v2 release to enable new features and extended support.

Implement Dependency RFC 0004 for dotnet-sdk

Implement Dependency Management RFC Phase 1 for dotnet-sdk. Check out the RFC for more details and background.

1. Determine dependency source strategy

Background

When possible, dependencies should be used directly from upstream, rather than undergoing any additional compilation or modifications performed by Paketo-maintained code. For each dependency, the corresponding buildpack maintainer group will decide if the dependency can be used directly from upstream, and must identify the location from which the dependency will be pulled from. Some of the Paketo Java buildpacks perform directory stripping during the buildpack build process itself. This could be a viable alternative to performing directory modifications during the dependency management process for maintainers to consider.

• Determine whether the dependency can be used directly from its upstream, rather than undergoing additional compilation/modification.

• If using directly from upstream, note where dependencies will come from
• If compiled or modified, note the decision for this

• Document decision in a language-family level RFC. This decision can be combined in the RFC with the decision made for other buildpacks in the language family.

2. Version retrieval and metadata generation code

Please refer to the retrieval RFC section on version retrieval for details around the API and background.

• Create retrieval code for the dependency

• Will live in the buildpack under: dependency/retrieval/
• Per the RFC, this will be a combination of (1) discovering new dependency versions based on the buildpack.toml, and (2) generating metadata for each new version.
• Note : Per the RFC caveat - if the dependency is to be compiled, the SHA256 and URI field from the metadata should be omitted in this step.

3. Compilation code (if needed)

If the dependency will be compiled/modified, then refer to the compilation RFC section for API details and background.

• Create compilation action

• Will live in the buildpack under: dependency/actions/compile/

4. Dependency testing (optional)

It's up to maintainer discretion if the dependency will be tested. It's recommended to test the dependency if it's been compiled. Check out the testing RFC section for details.

• Add tests for dependency

• Will live in the buildpack under: dependency/test.

5. Makefile Setup

When using the generalized workflows for dependency management down the line, version retrieval and dependency testing will be executed via a Makefile in order to provide the workflow a standardized way to run the code, regardless of what language it was written in. Check out the RFC section for what this should look like.

• Add Makefile

• Will live in the buildpack at: dependency/Makefile

6. Leveraging the new code

This issue serves to set up all the main logic for the dependency management. The work to actually leverage this code and migrate off of the dep-server will be completed in a separate issue once workflows and infrastructure is set up.

Implement RFC 0006

Describe the Enhancement

.NET Core RFC 0006 has been approved and merged.

Possible Solution

• This buildpack no longer need to move the dotnet cli into a .dotnet_root directory.
• This buildpack no longer needs to set the .dotnet_root on the path using an environment layer.

Motivation

This is part of paketo-buildpacks/dotnet-core#755.

Request to Use SHA256 in manifest instead of SHA512 to support Offline Kubernetes builds

The dependency-mapping service binding currently cannot be used in Kubernetes environments with buildpacks using SHA512 checksums, as the format for specifying an alternative checksum defined in RFC 10 includes a colon, which is not usable as a Kubernetes secret key. A related issue has been opened here: paketo-buildpacks/packit#521

To allow users to run dotnet builds in offline Kubernetes environments, would it be possible to use SHA256 in this buildpack's buildpack.toml until an alternate format has been defined?

Configuring GitBot is recommended

Pivotal provides the GitBot service to synchronize pull requests and/or issues made against public GitHub repos with Pivotal Tracker projects. This service does not track individual commits.

If you are a Pivotal employee, you can configure Gitbot to sync your GitHub repo to your Pivotal Tracker project with a pull request. An ask+cf@ ticket is the fastest way to get write access if you get a 404 to the config repo.

If you do not want have pull requests and/or issues copied from GitHub to Pivotal Tracker, you do not need to take any action.

If there are any questions, please reach out to [email protected].

Print deprecation warning about the ability to set SDK version via `buildpack.yml`

Following #152, .NET Core Maintainers have come to consensus that it does not make sense for users to be able to configure their own SDK version at this time.

Because of this, we should start emitting a warning that the ability to set a version through the buildpack.yml will be deprecated in the v1.0.0 release of the buildpack. We will not implement the BP_DOTNET_SDK_VERSION alternative at this time. This should be a similar warning to what we emit in dotnet-core-runtime

The docs should also be updated to include the deprecation. Add onto this draft PR

Failure: Approve bot PR workflow

Approve bot PR workflow failed.

Enable Debug Logging

With the merging of RFC 27 buildpacks should respect the BP_LOG_LEVEL environment variable and allow for debugging logging.

A good example of how to minimally implement this feature can be found in Go Build.

Failure: Go get update workflow

Go get update workflow failed.
Please take a look to ensure CVE patches can be released. (cc @pivotal-cf/commercial-buildpacks).

Cannot build .NET app

Hi,

Tell me if I'm missing something - but I'm getting errors trying to build a .NET app using this builder.

$ pack build hello --builder paketobuildpacks/dotnet-core-sdk

latest: Pulling from paketobuildpacks/dotnet-core-sdk
Digest: sha256:3baceaeb9ebcf93286033bbf2946b852b536a34adb1fa118c4ef07e10373c6d2
Status: Image is up to date for paketobuildpacks/dotnet-core-sdk:latest
ERROR: failed to build: invalid builder paketobuildpacks/dotnet-core-sdk: builder index.docker.io/paketobuildpacks/dotnet-core-sdk:latest missing label io.buildpacks.builder.metadata -- try recreating builder

Failure: Push Buildpackage workflow

Push Buildpackage workflow failed.

Restructure: Only provide the dotnet-sdk dependency

Background

This buildpack currently provides the dotnet-sdk dependency, which

• Installs a version of the SDK onto the $DOTNET_ROOT
• Installs a version of the Dotnet Core Driver on the $PATH

It always requires itself, dotnet-core-runtime and dontet-core-aspnet on both launch and build.

Proposal

In order to conform the the restructure rfc, this buildpack should provide the dotnet-sdk dependency and require nothing. This will greatly simplify its interaction with other buildpacks in the language family.

The buildpack should Install a specified version of the SDK onto the $DOTNET_ROOT
The buildpack should install a specified version of the Dotnet Core Driver on the $PATH
The buildpack should also be rewritten in a packit compliant way.