Re-builds of same app are producing different SHAs

[ciberkleid]

What happened?

Built and then re-built a simple go application.
Expected the second build to product an identical image (same SHA).
However, a second image was created (different SHA).

Steps to Reproduce Issue

I think it would happen with any Golang app, but to provide a specific example, this is what I tried:

git clone  https://github.com/eduk8s-labs/sample-app-go.git
pack build demo-go-app
docker images
# Rerun last two steps, notice new image with new SHA was created

Build Configuration

pack 0.20.0+git-66a4f32.build-2668

paketobuildpacks/builder:base (latest as of date this issue is created)

Participating buildpacks:
paketo-buildpacks/ca-certificates 2.3.2
paketo-buildpacks/go-dist 0.6.0
paketo-buildpacks/go-build 0.4.1

[fg-j]

I was able to reproduce the reported phenomenon with the sample app you provided and also with this Paketo sample app, with the following versions:

• pack 0.20.0+git-66a4f32.build-2668
• buildpack: paketo-buildpacks/go 0.1.10
• builder: paketobuildpacks/builder:0.0.21-buildpackless-full

I built and rebuilt the Paketo sample app, saw that the image SHA changed. I used docker inspect to get the metadata for the resulting image after each build. I then diffed these (see comparison result). The Go Build buildpack builds the app binary into the targets layer. The SHA of that layer changes between the builds. Seems like the buildpack isn't building a reproducible binary. @paketo-buildpacks/go-maintainers Is this expected behaviour?

[ryanmoran]

There are some things we are doing in this layer that will cause a new layer to be created in some cases. Those will be addressed in a PR to come soon. However, at the same time, I discovered a race in the buildpack lifecycle that affects global file permissions. We won't be able to create completely reproducible builds until that race is resolved.