update-builder and update-buildpack treat every URI as a docker image

[rwos]

package.toml (same with builder.toml) may contain non-docker-registry dependencies, say:

[buildpack]
  uri = "./"

[[dependencies]]
  uri = "https://www.example.com/my-buildpack.cnb"

[[dependencies]]
  uri = "./a/local/directory"

[[dependencies]]
  uri = "some/local/file.cnb"

The docs say (https://buildpacks.io/docs/reference/config/package-config/):

uri: A URL or path to an archive, a packaged buildpack (saved as a .cnb file), or a directory. If path is relative, it must be relative to the package.toml.

and that all works brilliantly with pack - jam gets confused though.

Expected Behavior

for the above package.toml, jam update-buildpack exits successfully without doing anything

for a builder.toml with similar [[buildpacks]] entries, jam update-builder exists successfully without doing anything

Current Behavior

jam update-buildpack treats everything as a docker image reference and tries to get manifests ("failed to execute: failed to get buildpackage ID for ...")

jam update-builder treats everything as a docker image reference and tries to get tags ("failed to execute: failed to list tags: GET ... [map[Action:pull Class: Name:some/local/file.cnb Type:repository]]")

Possible Solution

parse uri as a URI and only contact a docker registry if it's a urn:cnb:registry:... or a docker:// URL

Steps to Reproduce

• add a non-docker [[dependencies]] entry to a package.toml and run jam update-buildpack
• add a non-docker [[buildpacks]] entry to a builder.toml and run jam update-builder

Motivations

we're trying to use jam on builders/buildpacks that don't necessarily have every part coming in via a docker registry

[till]

I tried to poke around with this a bit today. As @rwos (who's my colleague) pointed out, the code expects that everything is a container registry.

I think there's already code in pack to handle everything, as I can basically run a pack buildpack inspect:

pack buildpack inspect https://github.com/paketo-community/go-generate/releases/download/v0.2.36/go-generate-0.2.36.cnb
Inspecting buildpack: https://github.com/paketo-community/go-generate/releases/download/v0.2.36/go-generate-0.2.36.cnb
Downloading from https://github.com/paketo-community/go-generate/releases/download/v0.2.36/go-generate-0.2.36.cnb
1.89 MB/1.89 MB

REMOTE ARCHIVE:

Stacks:
  ID: *
    Mixins:
      (omitted)

Buildpacks:
  ID                                  NAME                                VERSION        HOMEPAGE
  paketo-community/go-generate        Paketo Go Generate Buildpack        0.2.36         https://github.com/paketo-community/go-generate

Detection Order:
 └ Group #1:
    └ paketo-community/go-generate@0.2.36 

This is what kind of happens in the update-buildpack (and update-builder) command in order to determine versions, etc.. There's additional code to improve the logic to find "latest". So this would be another concern.

Long story short: if we could do something similar to this:
https://github.com/buildpacks/pack/blob/852fcaa56aefd5a0252c7292a8dc349ac00648fd/internal/commands/inspect_buildpack.go#L89

... then jam supports everything under the sun (according to the spec)? Would there be any interest to use this code (the pack.Client) and replace the code in jam with it?

[robdimsdale]

Would there be any interest to use this code (the pack.Client) and replace the code in jam with it?

Sure! I'm more than happy to see jam support a wider range of URIs (and, as you point out, everything that pack supports).