pack inspect does not provide ARGS for npm project

[kotapeter]

Summary

I can see the default web process command during the build time but the pack inspect does not show the same result. The ARGS is empty.

---

Reproduction

Steps

1. git clone https://github.com/kotapeter/pack-inspect-bug.git
2. cd pack-inspect-bug
3. pack build test --builder heroku/builder:22 --path=.
4. pack inspect test

Current behavior

ARGS is empty

Expected behavior

ARGS should display start

---

Environment

pack info

Pack:
  Version:  0.29.0+git-95c8060.build-4209
  OS/Arch:  darwin/arm64

Default Lifecycle Version:  0.15.2

Supported Platform APIs:  0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.10

Config:
  experimental = true
  
  [[trusted-builders]]
    name = "[REDACTED]"

docker info

Client:
 Version:    24.0.6
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.11.2-desktop.5
    Path:     /Users/kotapeter/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.22.0-desktop.2
    Path:     /Users/kotapeter/.docker/cli-plugins/docker-compose
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.0
    Path:     /Users/kotapeter/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.20
    Path:     /Users/kotapeter/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v0.1.0-beta.8
    Path:     /Users/kotapeter/.docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/kotapeter/.docker/cli-plugins/docker-sbom
  scan: Docker Scan (Docker Inc.)
    Version:  v0.26.0
    Path:     /Users/kotapeter/.docker/cli-plugins/docker-scan
  scout: Docker Scout (Docker Inc.)
    Version:  v1.0.7
    Path:     /Users/kotapeter/.docker/cli-plugins/docker-scout

Server:
 Containers: 69
  Running: 64
  Paused: 0
  Stopped: 5
 Images: 112
 Server Version: 24.0.6
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8165feabfdfe38c65b599c4993d227328c231fca
 runc version: v1.1.8-0-g82f18fe
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.4.16-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 10
 Total Memory: 15.61GiB
 Name: docker-desktop
 ID: 0e9c0476-a478-43ce-87c3-75b1a963632d
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

[kotapeter]

It works with version 0.27.0. Something got changed in version 28. 🤔

[jjbustamante]

Hi @kotapeter !

I managed to reproduce the error in the latest pack 0.32.0 version.

[kotapeter]

Since [email protected] the Command is an array based on @natalieparellano's change.

The problem is that we get just [0] from Entries here but it contains args too.

In this case the proc.Command.Entries value is:

[npm start]

My proposal is to use the rest parts of Entries if Args is nil.
PR: #1977

[jjbustamante]

@kotapeter thank you very much for this contribution!! ❤️

I am going to wait for @natalieparellano feedback here, because, I have some doubts about why she rolled back the commit that seems to fix this issue from the beginning. I do not remember the context of this.

[natalieparellano]

why she rolled back the commit that seems to fix this issue from the beginning

I vaguely recall that before Platform API 0.11, the build metadata label (io.buildpacks.build.metadata) processes list didn't contain the buildpack ID:

{
  "processes": [
    {
      "type": "<process-type>",
      "command": ["<command>"],
      "args": [
        "<args>"
      ],
      "direct": false,
      "working-dir": "<working-dir>",
      "buildpackID": "<buildpack ID>"                              <-- from here
    }
  ],
  "buildpacks": [
    {
      "id": "<buildpack ID>",
      "version": "<buildpack version>",
      "homepage": "<buildpack homepage>",
      "api": "<buildpack API version>"                              <-- and here, we can determine how to display the process
    }
  ],
...

In Platform 0.10, how to display the process is just a mystery when command has only one entry, because we don't know the Buildpack API. args could be "always args" or they could be "overridable args", we just don't know. But in Platform 0.11 and later, we can determine the Buildpack API from the buildpack ID.

Edit: if command has more than one entry, we can assume that overridable args are supported, so we don't need to know the Buildpack API exactly.

[natalieparellano]

I ran into this issue myself this morning. It is indeed quite annoying. pack inspect for getting the process list is kind of useless at the moment 😢

In case it helps others, the following command can grab the list from docker inspect: docker inspect <image> | jq -r '.[0].Config.Labels["io.buildpacks.build.metadata"]' | jq '.["processes"]'