Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing No buildpacks found! error message when buildpack.toml parsing fails #788

Open
joshwlewis opened this issue Feb 16, 2024 · 6 comments
Labels
bug Something isn't working libcnb-package

Comments

@joshwlewis
Copy link
Member

joshwlewis commented Feb 16, 2024

When trying to package a buildpack with an invalid toml, this is the messaging:

▹ cargo libcnb package                                                                                                                  130 ↵
🚚 Preparing package directory...
🖥️ Gathering Cargo configuration (for x86_64-unknown-linux-musl)
🏗️ Building buildpack dependency graph...
🔀 Determining build order...
❌ No buildpacks found!

In my case, it wasn't finding any buildpacks, because my buildpack.toml had [[stacks]] in it. While stacks is deprecated, it is still supported in Buildpack API 0.10 (https://github.com/buildpacks/spec/blob/7eb38d15fd3bd5bb5240584f0e70beb61913032c/buildpack.md?plain=1#L1143). Maybe there are two issues here:

  1. Instead of reporting no buildpacks found, maybe we could report that we found a buildpack.toml that wasn't correct?
  2. Maybe we should still support [[stacks]] in buildpack.toml, even if libcnb.rs ignores it? This is likely only a temporary issue, so I could go either way here.
@edmorley
Copy link
Member

edmorley commented Feb 16, 2024

The error message comes from:

#[error("No buildpacks found!")]
NoBuildpacksFound,

if build_order.is_empty() {
return Err(Error::NoBuildpacksFound);
}

Which implies that an earlier failed parsing error wasn't propagated, and instead the buildpack ignored/excluded from the dependency graph.

I think this might have the same root cause as #708.

@edmorley edmorley added libcnb-package bug Something isn't working labels Feb 16, 2024
@iloverink
Copy link

iloverink commented Feb 20, 2024

This also causes some confusion when using pack package against the packaged output of cargo libcnb package. The pack outputs the following error

ERROR: no compatible stacks among provided buildpacks

Adding [[stacks]] id = "*" seems to address that, but then I get this error from cargo libcnb package.

@edmorley
Copy link
Member

@iloverink Hi! What version of Pack CLI is that using?

@iloverink
Copy link

iloverink commented Feb 22, 2024

Hi @edmorley - 0.33.2+git-f2cffc4.build-5562 installed from the homebrew tap

@joshwlewis
Copy link
Member Author

joshwlewis commented Feb 22, 2024

This area is also problematic for https://github.com/heroku/languages-github-actions, which depends on libcnb-data for buildpack.toml parsing. It forces languages-github-actions to use libcnb-data 0.17.0 (so that buildpacks with [[stacks]] are supported), or libcnb-data 0.18.0 (so that buildpacks with[[targets]]] are supported). There isn't a parser that supports both, even though both are allowed in the Buildpack API 0.10 spec.

More about this over on heroku/languages-github-actions#199.

@edmorley edmorley changed the title Confusing messaging when packaging a buildpack with [[stacks]] Confusing No buildpacks found! error message when buildpack.toml parsing fails Feb 26, 2024
@edmorley
Copy link
Member

edmorley commented Feb 26, 2024

The comments in this issue so far have actually been about three separate things:

  1. That cargo libcnb package gives a confusing No buildpacks found! error message if buildpack.toml parsing fails.
  2. That libcnb-data would fail to parse a buildpack.toml that contained [[stacks]] even though the spec for Buildpack API 0.10 permits it.
  3. That Pack CLI's pack buildpack package has a bug that means it still requires [[stacks]] even if [[targets]] is specified, and otherwise fails with ERROR: no compatible stacks among provided buildpacks.

Issue (2) has been fixed by #789 and released in libcnb 0.19.0.

Issue (3) is an upstream Pack CLI bug unrelated to libcnb, for which I've filed:
buildpacks/pack#2047

This leaves just (1) as something we should improve in libcnb. As such, I've adjusted the issue title to be about just (1).

It's also quite likely that (1) is a duplicate of #708.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working libcnb-package
Projects
None yet
Development

No branches or pull requests

3 participants