feat(manager): Cloud Native Buildpacks project descriptor manager

[pbusko]

Changes

• Adds support for Cloud Native Buildpacks project descriptor manager
• Updates docker references to builder and/or buildpacks in the project.toml file

Context

project.toml file is a convenient way to keep Cloud Native Buildpacks configuration, when using pack CLI to produce OCI images. The project descriptor file contains references to OCI images used during build, which could be updated by Renovate

• Cloud Native Buildpacks
• Project Descriptor (and it's spec)

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ pbusko
❌ loewenstein-sap
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[rarkins]

Can we find a simpler name for this manager, maybe even "buildpacks"?

[pbusko]

Can we find a simpler name for this manager, maybe even "buildpacks"?

sounds good to me

[c0d1ngm0nk3y]

Can we find a simpler name for this manager, maybe even "buildpacks"?

How about cnb? buildpacks is maybe confusing - there are several versions of buildpacks. The abbreviation cnb (cloud native buildpacks) should be known to anyone project.toml.

[rarkins]

I'm pretty sure the CNF now have a trademark in buildpacks so this will be the only valid usage of that name

[Shegox]

I'm pretty sure the CNF now have a trademark in buildpacks so this will be the only valid usage of that name

They do: https://www.linuxfoundation.org/legal/trademarks

• Buildpacks®
• Buildpacks.io™
• Buildpacks.IO and Design (color)

[c0d1ngm0nk3y]

I'm pretty sure the CNF now have a trademark in buildpacks so this will be the only valid usage of that name

I don't think that matters since the v2 buildpacks are in CNCF, aren't they?

But probably the name dosn't really matter anyway. The end user will not have any contact unless a project.toml is present and for internal use there is still the readme.md if in doubt.

[HonkingGoose]

Thanks for applying my suggestions. The next time, please batch apply the suggestions. Here's how:

1. Go to your PR's Files changed tab.
2. Select the Add suggestion to batch button for each suggestion.
3. After batching all suggestions: commit.

Read GitHub Docs, incorporating feedback into your pull request to learn more.

[pbusko]

@HonkingGoose thank you, will definitely do it in the future. The contribution guide states:

PRs will always be squashed by us when we merge your work. Commit as many times as you need in your pull request branch.

So I thought that the number of commits/batching would make no difference

[HonkingGoose]

@HonkingGoose thank you, will definitely do it in the future. The contribution guide states:

PRs will always be squashed by us when we merge your work. Commit as many times as you need in your pull request branch.

So I thought that the number of commits/batching would make no difference

Yeah, that's a partial instruction! We really mean:

• Commit as often as you want
• But batch review suggestions (to limit GitHub notification noise)

I'm improving the instructions with:

• docs(contributing): improve instructions for batch applying review suggestions #30829

[HonkingGoose]

One small thing, after that the docs look good to me.

I'll let a maintainer check for technical accuracy.

[viceice]

otherwise LGTM

[rarkins]

Please update from main branch then run pnpm prettier-fix

[rarkins]

That's what my colleagues tried to hint at here and here.

I don't think they were hinting at catastrophic backtracking, and even if they were they should have spoken clearly, not hinted.

They wrote:

that regex would be rather complex itself

Sounds to me like "it's hard", not "it's impossible without catastrophic backtracking"

We try the regex approach to identify a docker ref. If we miss it, it will be ignored although it would work.

Sounds to me like "we might get it wrong"

[loewenstein-sap]

I don't think they were hinting at catastrophic backtracking, and even if they were they should have spoken clearly, not hinted.

They did not hint at "catastrophic backtracking" per se, but they were clearly speaking out for not going down the road of a complex regex.

Should we revert to the pre-regex state or what should be done on this PR to get it merged?

[pbusko]

the regex has been optimized, there should be no catastrophic backtracking issues anymore

[rarkins]

Does https://chatgpt.com/share/e/67349544-aa74-800b-9647-9bac228f5ba4 help?

[pbusko]

Does https://chatgpt.com/share/e/67349544-aa74-800b-9647-9bac228f5ba4 help?

unfortunately I have no access to the link, but the problem should be solved (at least GHAS marked all issues as solved)

[rarkins]

Does chatgpt.com/share/e/67349544-aa74-800b-9647-9bac228f5ba4 help?

unfortunately I have no access to the link, but the problem should be solved (at least GHAS marked all issues as solved)

Sorry, I thought "share link" would be public. Maybe not

Outdated

[renovate-release]

🎉 This PR is included in version 39.25.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 39.25.0

Your semantic-release bot 📦🚀