run shell:
pack build myapp --builder cnbs/sample-builder:bionic

error:
===> BUILDING
[builder] ---> Java buildpack
[builder] ---> Installing JDK
[builder]
[builder] gzip: stdin: unexpected end of file
[builder] tar: Child returned status 1
[builder] tar: Error is not recoverable: exiting now
[builder] ERROR: failed to build: exit status 2
ERROR: failed to build: executing lifecycle. This may be the result of using an untrusted builder: failed with status code: 145

Update roadmap labels based on #125

Add the Guidelines from buildpacks/rfcs#143.

The mentioned link is in the contributor's guide in the Contributions > RFCs section (the broken link). I'm not sure where to link it to, I'd be happy to submit a PR for this.

When clicking on link open a pull request in the Adopoters.MD file the link is broken, it is pointing master branch and it was renamed to main

Based on a conversation on Slack we found that there is no way for the public to find project maintainers.

A page with the various teams, their maintainers and contributors would be helpful.

Document that it is requirement for core team and maintainers. Encourage everyone to opt in!

cc @nebhale this is where we wanted to document and publicize this right?

Add Buildpack Authors' Tooling Sub-Team from buildpacks/rfcs#159.

This issue have been automatically created from pull request buildpacks/rfcs#234.

"ERROR: failed to launch: exec.d: failed to execute exec.d file at path '/layers/samples_java-maven/jdk/exec.d/jdk.sh': fork/exec /layers/samples_java-maven/jdk/exec.d/jdk.sh: permission denied" ,According to official deployment documents，docker run find a error that container don't run

Discussed in #168

From your official website it seems impossible to find the repositories of the buildpacks on Github.

Can you please clarify where are they located?

For example, take a Rails app that I want to pack, how can I get a list of all the buildpacks (Heroku, Pivotal, etc.) and their repo on Github (i.e. Github link)?

The purpose of this issue is to track tasks associated with getting Buildpacks for CNCF project graduation. The time it takes from opening a PR to final decision varies wildly and depends on what is uncovered in the review process, as you can see with Cilium taking nearly a year. But the average time seems to be 9 months.

Note: I've completely edited everything below to reflect the NEW application form as they just updated it within the last 2 weeks.

This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.

$PROJECT Graduation Application

v1.5
This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.

Project Repo(s): $URL
Project Site: $URL
Sub-Projects: $LIST
Communication: $SLACK

Project points of contacts: $NAME, $EMAIL

Graduation Criteria Summary for $PROJECT

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

Criteria

Application Process Principles

Suggested

N/A

Required

• Give a presentation and engage with the domain specific TAG(s) to increase awareness

• TAG provides insight/recommendation of the project in the context of the landscape

• All project metadata and resources are vendor-neutral.

• Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.
  • Met during Project's application on DD-MMM-YYYY.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

Required

• Clear and discoverable project governance documentation.

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

• Governance clearly documents vendor-neutrality of project direction.

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

• A number of active maintainers which is appropriate to the size and scope of the project.

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

• Project maintainers from at least 2 organizations that demonstrates survivability.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

• Document agreement that project will adopt CNCF Code of Conduct.

• CNCF Code of Conduct is cross-linked from other governance documents.

• All subprojects, if any, are listed.

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Contributor ladder with multiple roles for contributors.

Required

• Clearly defined and discoverable process to submit issues or changes.

• Project must have, and document, at least one public communications channel for users and/or contributors.

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

• Documentation of how to contribute, with increasing detail as the project matures.

• Demonstrate contributor activity and recruitment.

Engineering Principles

• Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.

• Document what the project does, and why it does it - including viable cloud native use cases.

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

• Roadmap change process is documented.

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

• Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

  • Release expectations (scheduled or based on feature implementation)
  • Tagging as stable, unstable, and security related releases
  • Information on branch and tag strategies
  • Branch and platform support and length of support
  • Artifacts included in the release.
  • Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.

• History of regular, quality releases.

Security

Note: this section may be augemented by a joint-assessment performed by TAG Security.

Suggested

• Achieving OpenSSF Best Practices silver or gold badge.

Required

• Clearly defined and discoverable process to report security issues.

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

• Document assignment of security response roles and how reports are handled.

• Document Security Self-Assessment.

• Third Party Security Review.

  • Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

• TOC verification of adopters.

Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

Adoption

Adopter 1 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

Adopter 2 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

Adopter 3 - $COMPANY/$INDUSTRY

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.
MONTH YEAR

Projects moving from incubation to graduation are tracked here: https://github.com/orgs/cncf/projects/27/views/9

Once we've checked off all the above, we can fill out the Graduation Proposal and submit a PR. Example of a current project's PR in consideration (Falco): cncf/toc#956 and some that have been recently approved: cncf/toc#952 cncf/toc#1000

I'm not sure, but IMHO all UTC times mentioned in this README.md should be +1 hour.

For example
https://github.com/buildpacks/community/blob/main/README.md?plain=1#L66
this is actually 19:00 UTC.

Am I right?

If so please note: #153

Are you using Buildpacks?

If you are using Buildpacks, first, we would like to Thank You! Our goal is to grow the community, improve Buildpacks and help each other.

The purpose of this issue

We are always interested in finding out who is using Buildpacks, what attracted you to using Buildpacks, how we can listen to your needs, and, if you are interested, help promote your organization.

• We have people reaching out to us asking, who uses Buildpacks in production?
• We’d like to listen to what you would like to see in Buildpacks and your scenarios.
• We'd like to help promote your organization and work with you.

What we would like from you

Submit a comment in this issue to include the following information, which would then also get included into the ADOPTERS.md file in this repo for others to see:

• Your organization or company
• Link to your website
• Your country
• Your contact info to reach out to you: blog, email, Kubernetes or CNCF Slack workspace handle, or Twitter (at least one).
• What is your scenario for using Buildpacks?
• Are you running you application in testing or production?
• OPTIONAL: Attach a PNG version of your logo to your comment to which we'd add to the ADOPTERS.md file.

If you have any questions please email us.

Are you using CNB in production?
Let us know about your use case by either commenting in this issue or opening a pull request adding yourself to ADOPTERS.md.

Is there any difference between the following two cases?

CASE 1

• Create a buildpack without Procfile
• then run launcher my command

CASE 2

• Define a Procfile with procname: my command
• then run procname

I need to run the final images inside Kubernetes and I don't see any difference between CASE 1 and CASE 2... Is there any substantial difference? Is there any security difference?

Should I always specify a Procfile (CASE 2) or I can just use launcher with any command (CASE 1)?

The Cloud Native Buildpacks Docker Hub repos (buildpacksio and (cnbs)(https://hub.docker.com/u/cnbs)) look pretty sketchy. cnbs is understandable, given that it seems like we only host sample/internal images (though we do reference it in our docs), but given that buildpacksio is a bit more external (we will soon be referring to it in our tekton task (tektoncd/catalog#434), and it is our "official" lifecycle/pack image), we should probably spend some effort making it a bit more trustworthy.

Some potential tasks may be:

• Add our logo for both cnbs and buildpacksio
• Add a description/logo to buildpacksio/lifecycle
• Add a description/logo to buildpacksio/pack

This issue is for tracking the usage of HashiCorp Go packages and software products in Cloud Native Buildpacks.

The CNCF is tracking the impact of the HashiCorp license change in cncf/foundation#617 and they're collecting the list of affected projects in cncf/foundation#619

• Supermajority is never defined
• What rights do contributors have?
• How exactly does somebody become a contributor? see
  eg

New contributors may be self-nominated or be nominated by existing contributors, and must be elected by a supermajority of that team's maintainers

• Who owns the leftover repos?
• Who owns community?

Use https://allcontributors.org/ to recognize our contributors

RFC 0062
buildpacks/rfcs#113

What do you think about having a generic buildpack that can pack/build any app that contains a Dockerfile?

Basically it would be a fallback, similar to a simple docker build, but having that would make pack (and similar) more complete.

Also, if in production you have some apps that use pack and other that use docker build, you could always use the same CNB entrypoint, without wondering every time how the image was built (pack / plain docker).

Our team has been experimenting with workflows around GitHub issue management. See google doc with our work in progress.

This issue is about automating that workflow once it has been established. Some ideas for how we will automate are (could be some combination of these):

• Maintain our own GitHub actions script: https://github.com/actions/github-script
• Use a third party action to label new issues: https://github.com/marketplace/actions/simple-issue-labeler
• Use a third party action to label inactive issues as stale: https://github.com/marketplace/actions/close-stale-issues
  • Potentially not as useful in its current form as we'd want to configure multiple values for exempt-issue-label
• Use dispatches:
  • buildpacks/community could have on: dispatch
  • Every repo could have a single line on: <issue created ...> dispatch to community

It may make sense to block this work on buildpacks/rfcs#53 so that we have consensus on how labels are managed.

I'm facing a really strange issue: some images i build with buildpack work in both docker and kubernetes, others only in docker and not in kubernetes. How can i get technical help? Thanks

Creating this issue to track integrations with other open source projects and platforms. This is so that we have a visible way to track projects that are considering CNB integrations and see if we can help out these projects if needed or track their progress/any blockers.

Edit - Moved to a discussion instead for better threading. See #100

Do buildpacks define any convention about the default port to use for the web server?

I mean, if I need to route the HTTP requests to a container built with pack (it can be any application built with any builder), is there a default port / convention?

By default, should I route the traffic to port 80, 3000, 8080 or something else?

There is no Heroku 22 buildpack... to my surprise the last one is Heroku 20 (heroku/buildpacks:20):

https://hub.docker.com/r/heroku/buildpacks/tags

Is there any explanation for this? When the heroku/buildpacks:22 will be available?