Tar ingest with current directory errors

[DMarby]

When running a module with an import of ingest:pack:tar:. defined, in order to import the current directory, an error is thrown. Note that it works with a subdirectory, eg ingest:pack:tar:./foo.

Example module file:

{
	"imports": {
		"base": "catalog:early.polydawn.io/monolith/busybash:v1:linux-amd64",
        "src": "ingest:pack:tar:."
	},
	"steps": {
		"ci_build": {
			"operation": {
				"inputs": {
					"/":       "base",
					"/task":   "src"
				},
				"action": {
					"exec": [
						"/bin/bash", "-c",
						"ls -lah"
					]
				}
			}
		},
	}
}

Error:

$ stellar emerge
module loaded
module contains 1 steps
module evaluation plan order:
  - 01: ci_build
stellar: cannot resolve imports: fork rio: unexpected halt: exit status 2
	stderr follows:
panic: errcat-category-filter-rejection at tar_pack.go:86 -- required rio.ErrorCategory, got errcat.errorCategory("unknown-category") (original error: archive/tar: write too long)

goroutine 1 [running]:
github.com/warpfork/go-errcat.RequireErrorHasCategoryOrPanic(0xc420261d10, 0x93bb20, 0xa8c810)
	/task/.gopath/src/github.com/warpfork/go-errcat/errcatAssertions.go:48 +0x78
go.polydawn.net/go-timeless-api/rio.ToError(0xa8fac0, 0xc42024a2a0, 0x4b3d3b00)
	/task/.gopath/src/go.polydawn.net/go-timeless-api/rio/rioErrors.go:66 +0x55
main.(*outputController).EmitResult(0xc420081720, 0x0, 0x0, 0x0, 0x0, 0xa8fac0, 0xc42024a2a0)
	/task/cmd/rio/main.go:317 +0x81
main.Parse.func6(0xa968e0, 0xc420065940)
	/task/cmd/rio/main.go:282 +0x87
main.Main(0xa968e0, 0xc420065940, 0xc42001c090, 0x9, 0x9, 0xa90700, 0xc42000c010, 0xa90720, 0xc42000c018, 0xa90720, ...)
	/task/cmd/rio/main.go:56 +0xbe
main.main()
	/task/cmd/rio/main.go:28 +0xf0

[warpfork]

O boy.

I think this happens if you've got the .timeless dir underneath that . path that you're ingesting. This causes some madness, because rio is packing your filesystem into a tar file under .timeless/warehouse/[...]... so it tries to pack itself into itself as it's going.

So, that's not going to work. By using a ./deeper/path you'll avoid this issue, or moving your .timeless dir to a path above your module that's doing this.

This error message is pretty trash, though.