paketo-buildpacks / dotnet-core-aspnet Goto Github PK

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)

What happened?

• What were you attempting to do?

Use the buildpack with an FDE

• What did you expect to happen?
  Buildpack installs a version of ASPNet that's compatible with the installed version of dotnet runtime.

• What was the actual behavior? Please provide log output, if possible.
  Build fails because the selected version of ASPNet is not available in the buildpack (instead of matching rolled-forward runtime version)

This is because the buildpack checks if RUNTIME_VERSION is set but does not explicitly require dotnet-runtime at build time.

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

• What buildpacks are you using? Please include versions.

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?
  See test failures in dotnet-execute buildpack

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

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.

Per paketo-buildpacks/dep-server#45, we should start consuming the .NET Core ASPNet dependency from the dep-server (https://api.deps.paketo.io/v1/dependency?name=dotnet-aspnetcore and https://deps.paketo.io/dotnet-aspnetcore/...) instead of the https://buildpacks.cloudfoundry.org/dependencies/dotnet-aspnetcore/... 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.

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

Summary

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

dotnet-framework:
  version: 2.1.14

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

BP_DOTNET_FRAMEWORK_VERSION="2.1.14"

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.

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.

Push Buildpackage workflow failed.

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.

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].

What happened?

When rebuilding a .Net app that use the ASPNet framework. My app failed to start on after a successful rebuild that reused the cached ASPNet layer.

Reproduction Steps using the fde-app in the dotnet-core integration testdata:

1. pack build test

base: Pulling from paketobuildpacks/builder
Digest: sha256:e8d07f29232083a162b1f0660de1ac5132c01b69f3491446b6cd423f78e2894f
Status: Image is up to date for paketobuildpacks/builder:base
base-cnb: Pulling from paketobuildpacks/run
Digest: sha256:d7ce225d0061cc80333a06577faeed266efe9e74c578470a948517b668b5630c
Status: Image is up to date for paketobuildpacks/run:base-cnb
0.10.2: Pulling from buildpacksio/lifecycle
Digest: sha256:c3a070ed0eaf8776b66f9f7c285469edccf5299b3283c453dd45699d58d78003
Status: Image is up to date for buildpacksio/lifecycle:0.10.2
===> DETECTING
[detector] 4 of 7 buildpacks participating
[detector] paketo-buildpacks/dotnet-core-runtime 0.1.6
[detector] paketo-buildpacks/dotnet-core-aspnet  0.1.5
[detector] paketo-buildpacks/icu                 0.0.100
[detector] paketo-buildpacks/dotnet-execute      0.3.1
===> ANALYZING
[analyzer] Previous image with name "test" not found
===> RESTORING
===> BUILDING
[builder] Paketo .NET Core Runtime Buildpack 0.1.6
[builder]   Resolving Dotnet Core Runtime version
[builder]     Candidate version sources (in priority order):
[builder]       runtimeconfig.json -> "3.1.0"
[builder]       <unknown>          -> "*"
[builder]
[builder]     No exact version match found; attempting version roll-forward
[builder]
[builder]     Selected dotnet-runtime version (using runtimeconfig.json): 3.1.11
[builder]
[builder]   Executing build process
[builder]     Installing Dotnet Core Runtime 3.1.11
[builder]       Completed in 5.229s
[builder]
[builder]   Configuring environment for build and launch
[builder]     DOTNET_ROOT -> "/workspace/.dotnet_root"
[builder]
[builder]   Configuring environment for build
[builder]     RUNTIME_VERSION -> "3.1.11"
[builder]
[builder] Paketo ASP.NET Core Buildpack 0.1.5
[builder]   Resolving Dotnet Core ASPNet version
[builder]     Candidate version sources (in priority order):
[builder]       RUNTIME_VERSION    -> "3.1.11"
[builder]       runtimeconfig.json -> "3.1.0"
[builder]
[builder]     Selected dotnet-aspnetcore version (using RUNTIME_VERSION): 3.1.11
[builder]
[builder]   Executing build process
[builder]     Installing Dotnet Core ASPNet 3.1.11
[builder]       Completed in 1.494s
[builder]
[builder]   Configuring environment
[builder]     DOTNET_ROOT -> "/workspace/.dotnet_root"
[builder]
[builder] Paketo ICU Buildpack 0.0.100
[builder]   Executing build process
[builder]     Installing ICU
[builder]       Completed in 670ms
[builder]
[builder] Paketo .NET Execute Buildpack 0.3.1
[builder]   Assigning launch processes
[builder]     web: /workspace/react-app --urls http://0.0.0.0:${PORT:-8080}
[builder]
===> EXPORTING
[exporter] Adding layer 'paketo-buildpacks/dotnet-core-runtime:dotnet-core-runtime'
[exporter] Adding layer 'paketo-buildpacks/dotnet-core-aspnet:dotnet-core-aspnet'
[exporter] Adding layer 'paketo-buildpacks/icu:icu'
[exporter] Adding 1/1 app layer(s)
[exporter] Adding layer 'launcher'
[exporter] Adding layer 'config'
[exporter] Adding layer 'process-types'
[exporter] Adding label 'io.buildpacks.lifecycle.metadata'
[exporter] Adding label 'io.buildpacks.build.metadata'
[exporter] Adding label 'io.buildpacks.project.metadata'
[exporter] Setting default process type 'web'
[exporter] *** Images (4b8080e4a6e4):
[exporter]       test
[exporter] Adding cache layer 'paketo-buildpacks/dotnet-core-runtime:dotnet-core-runtime'
Successfully built image test

1. docker run -it test

warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
      No XML encryptor configured. Key {48f5ad66-cc58-4223-a11c-914e8434e361} may be persisted to storage in unencrypted form.
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://0.0.0.0:8080
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /workspace

1. pack build test

base: Pulling from paketobuildpacks/builder
Digest: sha256:e8d07f29232083a162b1f0660de1ac5132c01b69f3491446b6cd423f78e2894f
Status: Image is up to date for paketobuildpacks/builder:base
base-cnb: Pulling from paketobuildpacks/run
Digest: sha256:d7ce225d0061cc80333a06577faeed266efe9e74c578470a948517b668b5630c
Status: Image is up to date for paketobuildpacks/run:base-cnb
0.10.2: Pulling from buildpacksio/lifecycle
Digest: sha256:c3a070ed0eaf8776b66f9f7c285469edccf5299b3283c453dd45699d58d78003
Status: Image is up to date for buildpacksio/lifecycle:0.10.2
===> DETECTING
[detector] 4 of 7 buildpacks participating
[detector] paketo-buildpacks/dotnet-core-runtime 0.1.6
[detector] paketo-buildpacks/dotnet-core-aspnet  0.1.5
[detector] paketo-buildpacks/icu                 0.0.100
[detector] paketo-buildpacks/dotnet-execute      0.3.1
===> ANALYZING
[analyzer] Restoring metadata for "paketo-buildpacks/dotnet-core-runtime:dotnet-core-runtime" from app image
[analyzer] Restoring metadata for "paketo-buildpacks/dotnet-core-aspnet:dotnet-core-aspnet" from app image
[analyzer] Restoring metadata for "paketo-buildpacks/icu:icu" from app image
===> RESTORING
[restorer] Restoring data for "paketo-buildpacks/dotnet-core-runtime:dotnet-core-runtime" from cache
===> BUILDING
[builder] Paketo .NET Core Runtime Buildpack 0.1.6
[builder]   Resolving Dotnet Core Runtime version
[builder]     Candidate version sources (in priority order):
[builder]       runtimeconfig.json -> "3.1.0"
[builder]       <unknown>          -> "*"
[builder]
[builder]     No exact version match found; attempting version roll-forward
[builder]
[builder]     Selected dotnet-runtime version (using runtimeconfig.json): 3.1.11
[builder]
[builder]   Reusing cached layer /layers/paketo-buildpacks_dotnet-core-runtime/dotnet-core-runtime
[builder]
[builder] Paketo ASP.NET Core Buildpack 0.1.5
[builder]   Resolving Dotnet Core ASPNet version
[builder]     Candidate version sources (in priority order):
[builder]       RUNTIME_VERSION    -> "3.1.11"
[builder]       runtimeconfig.json -> "3.1.0"
[builder]
[builder]     Selected dotnet-aspnetcore version (using RUNTIME_VERSION): 3.1.11
[builder]
[builder]   Reusing cached layer /layers/paketo-buildpacks_dotnet-core-aspnet/dotnet-core-aspnet
[builder]
[builder] Paketo ICU Buildpack 0.0.100
[builder]   Reusing cached layer /layers/paketo-buildpacks_icu/icu
[builder]
[builder] Paketo .NET Execute Buildpack 0.3.1
[builder]   Assigning launch processes
[builder]     web: /workspace/react-app --urls http://0.0.0.0:${PORT:-8080}
[builder]
===> EXPORTING
[exporter] Reusing layer 'paketo-buildpacks/dotnet-core-runtime:dotnet-core-runtime'
[exporter] Reusing layer 'paketo-buildpacks/dotnet-core-aspnet:dotnet-core-aspnet'
[exporter] Reusing layer 'paketo-buildpacks/icu:icu'
[exporter] Adding 1/1 app layer(s)
[exporter] Reusing layer 'launcher'
[exporter] Reusing layer 'config'
[exporter] Reusing layer 'process-types'
[exporter] Adding label 'io.buildpacks.lifecycle.metadata'
[exporter] Adding label 'io.buildpacks.build.metadata'
[exporter] Adding label 'io.buildpacks.project.metadata'
[exporter] Setting default process type 'web'
[exporter] *** Images (ca4fc140636e):
[exporter]       test
[exporter] Reusing cache layer 'paketo-buildpacks/dotnet-core-runtime:dotnet-core-runtime'
Successfully built image test

1. docker run -it test

It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=3.1.0&arch=x64&rid=ubuntu.18.04-x64

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

0.14.1+git-b630309.build-1353

• What buildpacks are you using? Please include versions.
  [email protected]

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Background

This buildpack currently provides the dotnet-aspnetcore dependency, which

• Provides a library of shared dll files needed for aspnet core apps

It always requires itself on launch, and the dotnet-runtime dependency on both build and launch. This is unnecessary because we might need these dll libraries during build if we want to build our app with dotnet publish, or only during launch if we want to run with app with dotnet run.

Proposal

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

The builldpack should Install a specified version of the dotnet-aspnetcore libraries into the correct location.

The buildpack should also be rewritten in a packit compliant way.

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-aspnetcore dependency dep-server metadata and the buildpack.toml so that this field is populated in the BOM

Describe the Enhancement

.NET Core RFC 0005 has been approved and merged. This issue is part of implementing it.

This buildpack is no longer needed for the Paketo .NET Core language family buildpack, per the accepted RFC. However, there are likely downstream consumers of this buildpack that will need time to migrate to the new https://github.com/paketo-buildpacks/dotnet-core-aspnet-runtime buildpack.

Possible Solution

Decide on a reasonable deprecation window for the buildpack. Start logging that this component buildpack is deprecated. Indicate that the buildpack is deprecated in the next release's Release Notes.

Motivation

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

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

1. Determine dependency source strategy

• 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.