Skip to content

artifact: relocate metadata when restoring into a new install directory #147

Description

@MeteorsLiu

Problem

Formula metadata can contain absolute paths to the build output directory. For example:

installDir, err := ctx.outputDir()
if err != nil {
    out.addErr err
    return
}
out.setMetadata "-L" + installDir + "/lib -lz"

The current Kodo cache stores this value in Artifact.Metadata and returns it unchanged after restoring the artifact. If the artifact was built in one workspace and restored into another, its files are restored correctly but the metadata still points to the old build directory.

The same problem affects archives produced by llar make -o: embedding the original absolute path makes the archive metadata dependent on the temporary build workspace.

Expected behavior

Artifact metadata should be relocatable with the artifact payload.

The archive should store the install directory as a template:

-L{{.InstallDir}}/lib -lz

When Kodo restores the artifact, the template should be expanded using the new install directory:

-L<restored-workspace>/madler/zlib@v1.3.2-arm64-darwin/lib -lz

Dependency metadata should travel in the same archive metadata file so a restored cache entry contains both its usage metadata and dependency list.

Proposed change

  • Add an internal metadata codec that encodes and decodes .llar/metadata.json.
  • Normalize the current install directory to {{.InstallDir}} while packing an artifact.
  • Expand {{.InstallDir}} to the destination install directory after unpacking.
  • Store metadata and dependencies inside the artifact archive instead of Artifact.Metadata.
  • Use archiver.PackFS and archiver.Unpack for Kodo artifacts.
  • Apply the same metadata encoding to archives produced by llar make -o.

Validation

A local zlib formula was built with path-bearing metadata. Its archive contained:

{
  "metadata": "-L{{.InstallDir}}/lib -lz"
}

The artifact was then uploaded to Kodo and restored into a different workspace. The returned metadata pointed to the restored directory, and lib/libz.a existed at that location.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions