Add documentation about running podman-build(1) with an oci-archive: tag

[nullfs]

Feature request description

I've been trying to figure out how to bypass the local container storage while building images and this is the only method I found:

user@linux:~/src/podman $ podman image list -a
REPOSITORY                       TAG               IMAGE ID      CREATED      SIZE
localhost/podman-pause           4.7.1-1698265439  99fd9faf5de6  2 days ago   835 kB
docker.io/library/mongo-express  1.0.0             156c460699a5  9 days ago   265 MB
docker.io/library/mongo          7.0.2             ee3b4d1239f1  2 weeks ago  753 MB
docker.io/library/ubuntu         23.04             639282825872  3 weeks ago  72.8 MB

user@linux:~/src/podman $ podman build -t oci-archive:container-image.tar --squash-all .
STEP 1/1: FROM ubuntu:23.04
COMMIT oci-archive:container-image.tar
Getting image source signatures
Copying blob af056870e023 done   | 
Copying config a4dfa01cc9 done   | 
Writing manifest to image destination
--> 

user@linux:~/src/podman $ podman image list -a
REPOSITORY                       TAG               IMAGE ID      CREATED      SIZE
localhost/podman-pause           4.7.1-1698265439  99fd9faf5de6  2 days ago   835 kB
docker.io/library/mongo-express  1.0.0             156c460699a5  9 days ago   265 MB
docker.io/library/mongo          7.0.2             ee3b4d1239f1  2 weeks ago  753 MB
docker.io/library/ubuntu         23.04             639282825872  3 weeks ago  72.8 MB

In the example above, the Containerfile consists of a single FROM ubuntu:23.04. The output of this undocumented (?) form of podman build is similar to what one would get after running untagged podman build followed by podman save, except it never saves any images to ~/.local/share/containers/storage.

Since the manual already mentions podman push <image> oci-archive:<path> and podman run oci-archive:<path>, it would be nice if podman build was documented in a similar way (unless this is some sort of experimental feature that users are not supposed to use).

Suggest potential solution

No response

Have you considered any alternatives?

No response

Additional context

host:
  arch: amd64
  buildahVersion: 1.32.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - pids
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: conmon_2.1.6+ds1-1_amd64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.6, commit: unknown'
  cpuUtilization:
    idlePercent: 97.3
    systemPercent: 0.39
    userPercent: 2.31
  cpus: 16
  databaseBackend: boltdb
  distribution:
    codename: lunar
    distribution: ubuntu
    version: "23.04"
  eventLogger: file
  freeLocks: 2048
  hostname: linux
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.2.0-33-generic
  linkmode: dynamic
  logDriver: json-file
  memFree: 60693598208
  memTotal: 66767912960
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns_1.4.0-3_amd64
      path: /usr/lib/podman/aardvark-dns
      version: aardvark-dns 1.4.0
    package: netavark_1.4.0-3_amd64
    path: /usr/lib/podman/netavark
    version: netavark 1.4.0
  ociRuntime:
    name: crun
    package: crun_1.8-1_amd64
    path: /usr/bin/crun
    version: |-
      crun version 1.8
      commit: 0356bf4aff9a133d655dc13b1d9ac9424706cac4
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  pasta:
    executable: ""
    package: ""
    version: ""
  remoteSocket:
    exists: false
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns_1.2.0-1_amd64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 17179865088
  swapTotal: 17179865088
  uptime: 5h 14m 49.00s (Approximately 0.21 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/user/.local/share/containers/storage
  graphRootAllocated: 60129542144
  graphRootUsed: 633274368
  graphStatus:
    Backing Filesystem: overlayfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 6
  runRoot: /run/user/1000/containers
  transientStore: true
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 4.7.1
  Built: 1698265439
  BuiltTime: Wed Oct 25 22:23:59 2023
  GitCommit: ef83eeb9c7482826672f3efa12db3d61c88df6c4
  GoVersion: go1.20.3
  Os: linux
  OsArch: linux/amd64
  Version: 4.7.1

[rhatdan]

Why not use a tmpfs for the storage?

[nullfs]

I guess you could just run everything with the --root flag set to a tmpfs mount point but this saves you some copying.

[rhatdan]

You can change the locatiion of your root directory using storage.conf

[github-actions]

A friendly reminder that this issue had no activity for 30 days.