Add validation support for empty/nil [[stacks]]

[joshwlewis]

Summary

A buildpack.toml without [[order]] and [[stacks]] tables fails to pass validation during pack buildpack package as mentioned in #2047.

[[stacks]] was deprecated in API 0.10. Based on my experience with many other software deprecations, deprecations are usually hints to stop using that feature. It's surprising to me that pack would ask to specify [[stacks]] while supporting a Buildpack API that marks [[stacks]] as deprecated.

This PR adds a new test (which fails on the main branch) that illustrates the problem. It also changes the validation a bit so that pack supports non-meta buildpacks without this table.

This change will add support for empty stacks for Buildpack API versions prior to 0.10. I believe this makes sense. Previous versions of the Buildpack API did not mark [[stacks]] as mandatory, though it looks like this validation may have been accidentally doing so for pack.

Output

Before

pack buildpack package procfile-test --config ../procfile-cnb/packaged/x86_64-unknown-linux-musl/debug/heroku_procfile/package.toml
ERROR: saving image: no compatible stacks among provided buildpacks

After

go run cmd/pack/main.go buildpack package procfile-test --config ../procfile-cnb/packaged/x86_64-unknown-linux-musl/debug/heroku_procfile/package.toml
Successfully created package procfile-test and saved to docker daemon

Documentation

• Should this change be documented?
  • Yes, see #___
  • No
  • Maybe. Should we be clearer about what deprecated means here? https://github.com/buildpacks/spec/blob/buildpack/v0.10/buildpack.md#buildpacktoml-toml-stacks-array

Related

Resolves #2047

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.69%. Comparing base (3356686) to head (a0bb25e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2081      +/-   ##
==========================================
+ Coverage   79.68%   79.69%   +0.02%     
==========================================
  Files         176      176              
  Lines       13246    13254       +8     
==========================================
+ Hits        10554    10562       +8     
  Misses       2022     2022              
  Partials      670      670              

Flag	Coverage Δ
os_linux	78.60% <100.00%> (-<0.01%)	⬇️
os_macos	76.33% <100.00%> (+0.06%)	⬆️
os_windows	79.09% <100.00%> (+0.02%)	⬆️
unit	79.69% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[jjbustamante]

Should we need to add b.buildpack.Descriptor().API().AtLeast("0.10") to the condition?

[joshwlewis]

I'm happy to do so if y'all want; just let me know. But my opinion is no. Old versions of the Buildpack API spec do not say that [[stacks]] is required or mandatory. It seems like [[stacks]] has been mandatory in pack because of this logic, and perhaps that was unintentional.

[jjbustamante]

I think I am going to ask for @jkutner, @natalieparellano, and @hone opinions.
I searched in the git history and I can see that having a stack is mandatory, but I also agree that I didn't find it in the spec.
I would add the condition b.buildpack.Descriptor().API().AtLeast("0.10") but I am not 100% sure

[natalieparellano]

Should we need to add b.buildpack.Descriptor().API().AtLeast("0.10") to the condition?

I would be okay leaving this out. Older buildpacks should be able to work on newer platforms (where stacks are not required) without having to make changes.

[jjbustamante]

This change will add support for empty stacks for Buildpack API versions prior to 0.10. I believe this makes sense. Previous versions of the Buildpack API did not mark [[stacks]] as mandatory, though it looks like this validation may have been accidentally doing so.

I agree that it seems the validation was enforcing the use of [[stacks]] although the spec doesn't explicitly said it is mandatory