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

Starting with go 1.21, there is an optional entry in go.mod for toolchain, and an associated environment variable GOTOOLCHAIN. This is part of a larger change in go 1.21 around toolchains and minimum go versions. See documentation and the blog post.

This issue is to capture thoughts around what we might want to do with this new information. If we identify actionable features we can link them here.

Based on my understanding, I don't think there's too much the buildpack can or should do with this information, as the go toolchain itself processes this information and acts accordingly.

One thing we could choose to do could be fail-fast during Detect if the requested go toolchain is greater than the available versions of go the buildpack provides. That could be contentious, however, as starting with go 1.21, the go toolchain will download the required version of golang automatically, and as a result Paketo Buildpacks could be viewed as unnecessarily restrictive. Of course, this automatic download wouldn't work in an offline environment, so the build will fail regardless of whether the failure is by the buildpack in Detect or by the toolchain in Build.

@brayanhenao and I are exploring creating a Bill Of Materials (BOM) buildpack for golang, similar in principle to: https://github.com/paketo-buildpacks/node-module-bom

This new buildpack would require go mod, and could probably benefit from the vendor directory being pre-populated during the build phase, as it will likely populate that directory if it hasn't already been done.

Both of those two things point to the BOM buildpack having a dependency on this buildpack, but currently I do not believe it is possible to express this relationship because this buildpack does not provide any dependencies for other buildpacks to detect.

One of the challenges I'm having with this idea is that I can't think of any meaningful information that this buildpack could provide that the BOM buildpack would actually use. All the BOM buildpack really needs to know is whether the go-mod-vendor buildpack passed its detect phase, and it could benefit from the go-mod-vendor buildpack running its build phase before it analyses the dependencies and produces a BOM.

I may be misunderstanding the way to represent dependent relationships between buildpacks, though, so please correct me if my understanding is wrong!

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?

N/A

What version of the buildpack you are using?

v0.0.49

If you were attempting to accomplish a task, what was it you were attempting to do?

Build an app using the following command:

pack build myapp -e BP_GO_TARGETS="./cmd/app/" -p <local source code path>

What did you expect to happen?

The app builds correctly.

What was the actual behavior?

Fails with:

[builder] Running `go install`
[builder] rename /layers/org.cloudfoundry.go-mod/go-mod/bin /layers/org.cloudfoundry.go-mod/app-binary/bin: file exists
[builder] ERROR: failed to build: exit status 103

Can you provide a sample app?

I can if you need me to. It should be east to replicate. The broken logic is in mod.go setAppName().

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

Make sure all import statements are updated to point at the paketo-buildpacks org!

I'm trying to build a vendored Go app that uses go modules, and seeing the following error.

pack build online-mod-app1 --buildpack gcr.io/paketo-buildpacks/go-dist --buildpack gcr.io/paketo-buildpacks/go-mod-vendor --buildpack gcr.io/paketo-buildpacks/go-build -v
Pulling image gcr.io/paketo-buildpacks/builder:full-cf
full-cf: Pulling from paketo-buildpacks/builder
Digest: sha256:a644524b74ce5e6f6aa061e4ca3da49c8ac763ba2a504accafbd3846a4b49505
Status: Image is up to date for gcr.io/paketo-buildpacks/builder:full-cf
Selected run image mirror index.docker.io/paketobuildpacks/run:full-cnb-cf
Pulling image index.docker.io/paketobuildpacks/run:full-cnb-cf
full-cnb-cf: Pulling from paketobuildpacks/run
Digest: sha256:5bfb17205e2f528b91e10db7adca72c9e1689e189fad23cf5ab8793fc1b7201e
Status: Image is up to date for paketobuildpacks/run:full-cnb-cf
Pulling image gcr.io/paketo-buildpacks/go-dist
latest: Pulling from paketo-buildpacks/go-dist
d66019a3339b: Pull complete
Digest: sha256:9d13aca199d38cbd95d73b97f05dd354cb2ffaf1732c3349a9fbe63042b00bac
Status: Downloaded newer image for gcr.io/paketo-buildpacks/go-dist:latest
Pulling image gcr.io/paketo-buildpacks/go-mod-vendor
latest: Pulling from paketo-buildpacks/go-mod-vendor
Digest: sha256:e36c7b2a942291afffe28252fd41a5261486bec8e4eaa6970a1ce827e3566b22
Status: Image is up to date for gcr.io/paketo-buildpacks/go-mod-vendor:latest
Pulling image gcr.io/paketo-buildpacks/go-build
latest: Pulling from paketo-buildpacks/go-build
ef125ae8f7da: Pull complete
Digest: sha256:033f59236c80a068561c0a56bca9c55103f9bf57b2052d2beffc183536c7cdba
Status: Downloaded newer image for gcr.io/paketo-buildpacks/go-build:latest
Adding buildpack paketo-buildpacks/go-dist version 0.0.193 to builder
Adding buildpack paketo-buildpacks/go-mod-vendor version 0.0.148 to builder
Adding buildpack paketo-buildpacks/go-build version 0.0.15 to builder
Setting custom order
Creating builder with the following buildpacks:
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
Using build cache volume pack-cache-cc3907c23dda.build
===> DETECTING
======== Output: paketo-buildpacks/[email protected] ========

failed
======== Results ========
pass: paketo-buildpacks/[email protected]
fail: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: failed to detect: no buildpacks participating
ERROR: failed with status code: 1

Can reproduce with the following fixture https://github.com/paketo-buildpacks/go-mod-vendor/tree/master/integration/testdata/default and vendoring the app beforehand.

What happened?

• What were you attempting to do?

Trying to build a go app that has vendored dependencies with go 1.16. The go.mod file has:

go 1.16

• What did you expect to happen?

This should build the app image with go 1.16

• What was the actual behavior? Please provide log output, if possible.

This buildpack failed to detect and the go-dist buildpack expected either BP_GO_VERSION to be set in the environment or through the buildpack.yml (which is deprecated.) This means that a user needs to specify the version of go in an additional location than just using the go.mod file to verify the version required.

===> BUILDING
[builder] Paketo Go Distribution Buildpack 0.3.0
[builder]   Resolving Go version
[builder]     Candidate version sources (in priority order):
[builder]       <unknown> -> ""
[builder]
[builder]     Selected Go version (using <unknown>): 1.15.8
[builder]
[builder]   Reusing cached layer /layers/paketo-buildpacks_go-dist/go

Build Configuration

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

pack latest cli

• What buildpacks are you using? Please include versions.

go buildpack v0.4.0

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

custom but not relevant

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

no buildpack config

Checklist

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

Create Draft Release workflow failed.

We should support building Go apps with version defined in the go.mod file as this is fairly standard practice.

Acceptance
GIVEN I have a Go app that uses Go Modules
AND it sets the version of Go to use in the go.mod file
WHEN I pack build it
THEN I should see that the app is built with the go version defined in go.mod

Update GitHub config workflow failed.

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

What version of the buildpack you are using?

master

If you were attempting to accomplish a task, what was it you were attempting to do?

Pass ldflags with a version so that our binary could be built with version information. For example, -ldflags -X github.com/example.com/cmd.Version=1.2.3

What did you expect to happen?

The resulting image would have our app binary and the version reported by that app binary would be what was passed via ldflags.

What was the actual behavior?

The version reported by the binary is never set.

Can you provide a sample app?

We are attempting to do this on github.com/pivotal/kpack. The Version is set in the file cmd/version.go and the ldflags we pass in the buildpack.yaml looks like the following:
"github.com.pivotal.kpack.cmd.Version": "1.2.3"

This bug was exposed after fixing the ldflags behavior with PR #11

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

If an app has multiple targets, then all of the targets will be built but, only the first target will actually be exported in the resulting image.

For example in an app with the following buildpack.yaml, only binaryone will be in the resulting image.

go:
  targets: ["./cmd/binaryone", "./cmd/binarytwo", "./cmd/binarythree"]

This codebase should be rewritten to take advantage of the new packit library.

What version of the buildpack you are using?

0.0.58

If you were attempting to accomplish a task, what was it you were attempting to do?

I'm trying to see the contents of my go.mod file attached to the image for OSL verification

What did you expect to happen?

The module information was somehow passed along

What was the actual behavior?

± zm |master U:1 ?:1 ✗| → inspect-bom gcr.io/cncf-buildpacks-ci/pm/github-actions-automate-projects:sandbox | jq
{
  "bom": [
    {
      "name": "go",
      "version": "1.13.4",
      "metadata": {
        "licenses": [],
        "name": "Go",
        "sha256": "692d17071736f74be04a72a06dab9cac1cd759377bd85316e52b2227604c004c",
        "stacks": [
          "io.buildpacks.stacks.bionic",
          "org.cloudfoundry.stacks.tiny"
        ],
        "uri": "https://dl.google.com/go/go1.13.4.linux-amd64.tar.gz"
      },
      "buildpack": {
        "id": "org.cloudfoundry.go-compiler",
        "version": "0.0.55"
      }
    },
    {
      "name": "",
      "version": "",
      "metadata": null,
      "buildpack": {
        "id": "org.cloudfoundry.go-compiler",
        "version": "0.0.55"
      }
    },
    {
      "name": "",
      "version": "",
      "metadata": null,
      "buildpack": {
        "id": "org.cloudfoundry.go-mod",
        "version": "0.0.58"
      }
    }
  ],
  "buildpacks": [
    {
      "id": "org.cloudfoundry.go-compiler",
      "version": "0.0.55"
    },
    {
      "id": "org.cloudfoundry.go-mod",
      "version": "0.0.58"
    }
  ],
  "launcher": {
    "version": "0.5.0",
    "source": {
      "git": {
        "repository": "https://github.com/buildpack/lifecycle",
        "commit": "f0a279f"
      }
    }
  }
}

inspect-bom is a function
inspect-bom ()
{
    image=$1;
    docker inspect "${image}" | jq '.[].Config.Labels | .["io.buildpacks.build.metadata"] ' | jq -r
}

Can you provide a sample app?

https://github.com/Zanadar/github-actions-automate-projects/tree/25b8a6c59f8e09344531d8363986b0c6b2d3355a

In order to implement the Go re-architecture RFC we should rename this buildpack to go-mod-vendor. ID should also be changed to go-mod-vendor.

After this change is made and the buildpack is packit re-written, ordering in the language family Go Buildpack should be something like:

[[order]]
  [[order.group]]
    id = "go-dist"
  [[order.group]]
    id = "go-mod-vendor"
  [[order.group]]
    id = "go-build"
..........................

Currently the entire gocache is stored in one layer. The same is true for the go modules. We may be able to improve layer caching/restoring performance if we slice the gocache and go mod layers into many separate layers. I don't have any actual evidence that this will improve performance, but it makes sense on a conceptual level as very few things will change in the modules and cache between builds. Finally, the layout of the gocache and the go modules directories are already setup for convenient slicing because they contain well distributed sub-directories.

I think we can simplify the logic around Detect failing if go.mod is not present by leveraging the fs.Exists() method in packit. We would check the existence of the file first, returning early if it does not exist (or errors when trying to determine if the file exists), and then moving on to parsing it once we know it exists.

I'm happy to submit a PR for this if you agree.

We should looking into adding support for apps that have multiple go.mod files.

Helpful links:

• https://github.com/paketo-buildpacks/go-mod-cnb/blob/master/cmd/detect/main.go#L36
• https://github.com/paketo-buildpacks/go-mod-cnb/blob/master/mod/mod.go#L51

Acceptance
pack build should succeed when building a multi-module golang app using go modules

In a corporate setting we use Artifactory to as a pull through for go packages. In order for it to work GOPROXY, GONOPROXY, GOSUMDB, GONOSUMDB, and GOPRIVATE need to be configurable.

Describe the Enhancement

Set GOPROXY, GONOPROXY, GOSUMDB, GONOSUMDB, and GOPRIVATE in a build pipeline/locally and run pack build image with the env variables seamlessly passing to go mod vendor.

Possible Solution

Motivation

In a corporate setting network requests can be man-in-the-middled by security software. Requests for go packages need to use go_proxy

Using master of go-mod-cnb

What version of the buildpack you are using?

master branch

If you were attempting to accomplish a task, what was it you were attempting to do?

Build source code using the go-mod-cnb buildpack where a module references code from a private git repo.

What did you expect to happen?

I expected some input or method to provide credentials to the buildpack to build the container image.

What was the actual behavior?

We got the following error as when git tried to fetch from a private repo, it wanted to prompt the user for a username and password to access, but couldn't.

[builder] go: finding github.com/cmccarthy101/test10 v0.0.0-20190508160027-f70a194aee79
[builder] go: github.com/cmccarthy101/[email protected]: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /layers/org.cloudfoundry.go-mod/go-mod/pkg/mod/cache/vcs/1c0e1ed356a540e8b5b7244633737b2ebac6042801011dba950572c2525b76c3: exit status 128:
[builder] 	fatal: could not read Username for 'https://github.com': terminal prompts disabled

Can you provide a sample app?

https://github.com/cmccarthy101/test11.git

// @BenChapman

What happened?

• What were you attempting to do?

Building a go+react app. The directory structure is such that the go.mod file is at the root and there is a subdirectory called web that contains the node stuff.

• What did you expect to happen?

Builds after zero changes to be really fast.

• What was the actual behavior? Please provide log output, if possible.

Builds were slow and it seems generating the SBOM is where most of the time is spent (~28s):

Paketo Go Mod Vendor Buildpack 0.5.0
  Checking module graph
    Running 'go mod graph'
      Completed in 752ms

  Executing build process
    Running 'go mod vendor'
      Completed in 462ms

  Generating SBOM for directory /workspace
      Completed in 28.804s

When I run pack --sbom-output-dir /tmp I can see that /tmp/sbom/build/paketo-buildpacks_go-mod-vendor/sbom.syft.json contains all the node dependencies in addition to the go dependencies.

It looks like on this line the parameter to the sbom generator is pointing to entire workingDir and I suppose I expect to be more specific like just go.mod?

Build Configuration

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

pack --version
0.24.0+git-79a40b7.build-3148

Checklist

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

Publish All Draft Releases workflow failed.

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?
N/A - Was testing the go-mod using kpack

What version of the buildpack you are using?
[email protected]

If you were attempting to accomplish a task, what was it you were attempting to do?
Rebuild an image using kpack where caching was enabled

What did you expect to happen?
The image would be re-built using the cached layers

What was the actual behavior?
The lifecycle of CNB fails at restore as the layer tar can be uncompressed

Restoring cached layer 'org.cloudfoundry.go-mod:go-mod'
Error: failed to restore: mkdir /layers/org.cloudfoundry.go-mod/go-mod/pkg/mod/github.com/bstick12/[email protected]/.circleci: permission denied

The previous layer is correctly used from cache

Restoring cached layer 'org.cloudfoundry.go-compiler:ac2a6efcc1f5ec8bdc0db0a988bb1d301d64b6d61b7e8d9e42f662fbb75a2b9b'
Restoring cached layer 'org.cloudfoundry.go-compiler:go'

The problem lies with the go module package paths. The package directories are not writeable. Apparently this is by design as discussed in golang/go#27161 and golang/go#27455 (comment)

  File: /layers/org.cloudfoundry.go-mod/go-mod/pkg/mod/github.com/bstick12/[email protected]/
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 6ch/108d	Inode: 300555      Links: 4
Access: (0500/dr-x------)  Uid: ( 1000/     cnb)   Gid: ( 1000/     cnb)

This permission is preserved in the tarball

dr-x------ 1000/1000         0 1980-01-01 00:00 /layers/org.cloudfoundry.go-mod/go-mod/pkg/mod/github.com/bstick12/[email protected]
d

Since without a change to the tar or untaring process for this buildpack the caching process will break. Would be possible to disable caching.

Can you provide a sample app?

The behaviour should be the same for any go application that use go modules.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

Requests for being able to use private repos as go modules has come up a couple times and probably something we should consider. Here's a recent question from @cirocosta around this:

is it correct to say that the credentials used for the prepare step are not injected into the build step?
the use case: i’ve got a private repo that depends on other private repos (via go modules) and I currently don’t vendor them all into the first - build currently seems unable to fetch those private dependencies

I'm filing this here as the specific request is around go modules, but likely that there's a solution for this across all buildpacks.

As of Go 1.15 user could specify GOMODCACHE to indicate a location of the go mod cache
golang/go#31283

We should update our code here to use that environment variable.

After the buildpack finishes its integration test there are still containers left running on the machine. The integration tests should fully clean themselves up.

We have a reference to the "tiny" stack in our codebase here. The stack ID is changing from org.cloudfoundry.stacks.tiny to io.paketo.stacks.tiny as can be seen in #49. At some point in the future, the old "tiny" stack ID will be removed. By that point we will need to be referencing the new ID.

Push Buildpackage workflow failed.

What happened?

• What were you attempting to do?
  I was trying to build an app with go 1.12 in my go.mod file.

• What did you expect to happen?

  I expected it to build with the language features present in Go 1.12 as outlined in the documentation.

• What was the actual behavior? Please provide log output, if possible.

  It prints that it cannot find a 1.12 version of Go.

  Paketo Go Distribution Buildpack 0.2.6
    Resolving Go version
      Candidate version sources (in priority order):
        go.mod    -> "1.12.*"
        <unknown> -> ""
  failed to satisfy "go" dependency version constraint "1.12.*": no compatible versions. Supported versions are: [1.14.12, 1.14.13, 1.15.5, 1.15.6]
  ERROR: failed to build: exit status 1
  

Build Configuration

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

  pack 0.15.1+git-79adc30.build-1660

• What buildpacks are you using? Please include versions.

  https://github.com/paketo-buildpacks/go/releases/tag/v0.3.0

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

  module example-app
  
  go 1.12
  

Checklist

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

Its super common in the wild for -ldflags to have more than just -X, eg -s -w and especially --extldflags -static. Could we support this? Or alternately, provide a config switch that would just add a handful of sane defaults like clean: true->-ldflags -s -wandstatic: true->-ldflags "-extldflags -static"`

What version of the buildpack you are using?
org.cloudfoundry.go-mod- 0.0.29

What did you expect to happen?
I expected the built binary to be on the pack at launch.

What was the actual behavior?
The app binary is in /layers/org.cloudfoundry.go-mod/app-binary/build-init instead of /layers/org.cloudfoundry.go-mod/app-binary/bin/build-init

Can you provide a sample app?
http://github.com/pivotal/kpack

If the go.mod file does not have any required packages, the mod-cache layer is empty and breaks caching:

go.mod

module example.com/mymodule

go 1.13

Build output:

$pack build example.com/myapp --buildpack gcr.io/paketo-buildpacks/go --no-pull
===> DETECTING
[detector] paketo-buildpacks/go-dist       0.0.193
[detector] paketo-buildpacks/go-mod-vendor 0.0.148
[detector] paketo-buildpacks/go-build      0.0.15
===> ANALYZING
[analyzer] Previous image with name "example.com/myapp:latest" not found
===> RESTORING
===> BUILDING
[builder] Go Distribution Buildpack 0.0.193
[builder]   Resolving Go version
[builder]     Candidate version sources (in priority order):
[builder]       <unknown> -> ""
[builder]       <unknown> -> ""
[builder]
[builder]     Selected Go version (using <unknown>): 1.14.6
[builder]
[builder]   Executing build process
[builder]     Installing Go 1.14.6
[builder]       Completed in 28.244s
[builder]
[builder] Go Mod Vendor Buildpack 0.0.148
[builder]   Executing build process
[builder]     Running 'go mod vendor'
[builder]       Completed in 79ms
[builder]
[builder] Go Build Buildpack 0.0.15
[builder]   Executing build process
[builder]     Running 'go build -o /layers/paketo-buildpacks_go-build/targets/bin -buildmode pie .'
[builder]       Completed in 31.047s
[builder]
[builder]   Assigning launch processes
[builder]     web: /layers/paketo-buildpacks_go-build/targets/bin/go-online
===> EXPORTING
[exporter] Adding layer 'paketo-buildpacks/go-build:targets'
[exporter] Adding 1/1 app layer(s)
[exporter] Adding layer 'launcher'
[exporter] Adding layer 'config'
[exporter] Adding label 'io.buildpacks.lifecycle.metadata'
[exporter] Adding label 'io.buildpacks.build.metadata'
[exporter] Adding label 'io.buildpacks.project.metadata'
[exporter] *** Images (f8168ad499d0):
[exporter]       example.com/myapp:latest
[exporter] Adding cache layer 'paketo-buildpacks/go-dist:go'
[exporter] Warning: Failed to export cache: failed to cache layer 'paketo-buildpacks/go-mod-vendor:mod-cache' because it has no contents
Successfully built image example.com/myapp

If there is nothing in the layer, we should remove it.

Approve bot PR workflow failed.

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of

running cf curl /v2/info && cf version?
pack cli v0.1.0 (git sha: e1793ab9fc3d172a416183ef3df20daf089eba19)

What version of the buildpack you are using?

v0.2.0

If you were attempting to accomplish a task, what was it you were attempting to do?

N/A

What did you expect to happen?

Source code should not be included in the run container once the Go code has been compiled

What was the actual behavior?

Source code was included in the run container once the Go code was compiled

Can you provide a sample app?

Any app will do

/cc @BenChapman

Problem

When an image is created with go src code that does not contain a main package, the build phase logs the following:

[builder] Running `go install`

[builder] rename /layers/paketo-buildpacks_go-mod/go-mod/bin/helloworldgo /layers/
paketo-buildpacks_go-mod/app-binary/bin/helloworldgo: no such file or directory

[builder] ERROR: failed to build: exit status 103
ERROR: failed with status code: 7

This doesn't tell the user that the problem lies in the source code and not in the buildpack

Suggestion

Log an error message to the effect of failed to create a valid executable.

$ docker run -ti cloudfoundry/cnb:cflinuxfs3 bash -euc "ls /buildpacks/org.cloudfoundry.go-mod/"
0.0.9  latest

Sorry for using issues for my own learning.

Why is 0.0.15 the latest version of this buildpack (7 days ago), but https://github.com/cloudfoundry/go-mod-cnb/releases/tag/v0.0.9 from 26 days ago is the version in the builder?

Describe the Enhancement

Currently the buildpack runs go mod graph to check and see if there are any dependencies present in the go.mod file and if the file is empty we skip running go mod vendor. This however has been reported by users to cause a slow rebuild as the go mod graph itself can take upwards of a minute.

Possible Solution

I think that we should remove the go mod graph check and just run go mod vendor if there is a go.mod file present in the workspace. This may be a minor penalty for user that have a go.mod file with no packages but ultimately the go mod vendor command does not fail if there are no packages and it outputs a message similar to what we output on our own scan.

Motivation

I think that there is a very little reason not to do this. It will simplify the build logic and will have almost identical output to users that have go.mod files with no packages present.