paketo-buildpacks / dep Goto Github PK
View Code? Open in Web Editor NEWA Cloud Native Buildpack for Go Dep
License: Apache License 2.0
A Cloud Native Buildpack for Go Dep
License: Apache License 2.0
What version of the buildpack you are using?
0.0.1
If you were attempting to accomplish a task, what was it you were attempting to do?
Build using the dep-cnb
What did you expect to happen?
When I have a detect failure I get useful error messages
What was the actual behavior?
I just see that the detection fails.
The following failures return an error of nil. They should return useful error messages to the user about the detection failure.
Can you provide a sample app?
Any go dep application
Please confirm where necessary:
Currently, if you do not have a buildpack.yml
or if its missing go.import-path
then the dep-cnb
fails:
===> BUILDING
[builder]
[builder] Go Compiler Buildpack v0.0.27
[builder] Go 1.13: Contributing to layer
[builder] Downloading from https://buildpacks.cloudfoundry.org/dependencies/go/go1.13.linux-amd64-cflinuxfs3-8b3c3fb8.tar.gz
[builder] Verifying checksum
[builder] Expanding to /layers/org.cloudfoundry.go-compiler/go
[builder]
[builder] Dep Buildpack v0.0.26
[builder] failure running build: no import-path found in buildpack.yml
[builder] Error: failed to build: exit status 102
But this is a slow failure - you've had to wait ages (depending on internet speed) for go1.13.linux-amd64-cflinuxfs3-8b3c3fb8.tar.gz to be downloaded first - to get an error that isn't obvious. So you fail a few more times before you read the various integration/test-data/
apps to see what a buildpack.yml
is supposed to look like.
Instead, could bin/detect fail or generate a warning ASAP if buildpack.yml
is missing or misformed?
Create Draft Release workflow failed.
To confirm 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.
This codebase should be rewritten to take advantage of the new packit library.
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.
What version of the buildpack you are using?
0.0.7
If you were attempting to accomplish a task, what was it you were attempting to do?
Build a go app that has fresh changes
What did you expect to happen?
The app-layer is not reused, instead a new layer is exported.
What was the actual behavior?
The app-layer is reused.
Can you provide a sample app?
This should fail with any go app as long as you do not update the Gopkg.lock
Please confirm where necessary:
Create Draft Release workflow failed.
What version of the buildpack you are using?
0.0.1
If you were attempting to accomplish a task, what was it you were attempting to do?
Use the buildpack to build a go lang dep application
What did you expect to happen?
I expected the buildpack to work without a buildpack.yml as there is no documentation
What was the actual behavior?
The detect steps fails with no useful error message
[detector] ======== Results ========
[detector] fail: Dep Buildpack
I had to read the source code to understand that a buildpack.yml is required. And that the structure of the buildpack.yml should be the following
---
import-path: github.com/pivotal/go-hello-world
Also have questions about the value of import-path
. The structure doesn’t seem to be validated and will take any value which just ends up being the application name. Perhaps it might be better named. e.g application-name
Can you provide a sample app?
N/A
Please confirm where necessary:
Per paketo-buildpacks/dep-server#45, we should start consuming the dep
dependency from the dep-server (See https://api.deps.paketo.io/v1/dependency?name=dep for dependency metadata) instead of the https://buildpacks.cloudfoundry.org/dependencies/dep/... 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.
Create Draft Release workflow failed.
Currently the generated binary is placed in /layers/org.cloudfoundry.dep/app-binary/
folder, which is not picked up by $PATH
.
Instead, could the binary be placed in $PATH
, e.g. a folder ending in /bin
?
0.0.1
Build an application when the main isn't at the root of the source directory
I should be able to configure the buildpack to allow it build source from a location not at the root of the source directory
This would be similar to the proposed behaviour detailed in paketo-buildpacks/go-mod-vendor#2
There is no configuration option available
Can you provide a sample app?
N/A
Make sure all import statements are updated to point at the paketo-buildpacks org!
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].
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.