Restore Cache succeeds with tar: Error opening archive message

[jeremysimmons]

This log shows that the message tar: Error opening archive: Failed to open. Clearly the task did not succeed, but it is marked as such.

I believe the fault is with the failure to check the return code when calling tar in cacheUtilities.downloadCaches

azure-pipelines-artifact-caching-tasks/Tasks/Common/packaging-common/cache/cacheUtilities.ts

Line 91 in 7b16b67

shell.exec(`tar -xzf ${tarballPath} -C "${destinationFolder}"`);

try {
    tl.setVariable(hash, "true");
    // only if tar succeeds should we indicateit succeeded
    const success = shell.exec(`tar -xzf ${tarballPath} -C "${destinationFolder}"`).code == 0);
    // Set variable to track whether or not we downloaded cache (i.e. it already existed)
    tl.setVariable(output, success ? "true" : "false");
    return;
    }
} catch (err) {
    console.log(err);
}

[ethanis]

Thanks for taking the tasks for a spin!

It's by design that we don't fail the tasks on internal errors. This is because the tasks have the opinion that a cache hit/miss are tangential to a successful build and shouldn't cause false failures.

If you share verbose build logs, I can try to help troubleshoot what the issue may be.

[jeremysimmons]

It's by design that we don't fail the tasks on internal errors.
That failed to violate the principal of least surprise for me.

verbose build logs
I assume you mean this versbose logging.
I will use system.debug set to true to keep this on all the time so I can provide some Telemetry.

When it fails, the variable CacheRestored-Server is set to true. (we use "Server") as the alias for this.
Clearly, it was not restored, because tar failed to open and read the file, and expand to the target folder. I don't understand why this isn't considered a failure of the task to do what it's advertising.

Also, this version of the Restore Cache task seems to be superceded by Pipeline Caching. Is that correct?

[jeremysimmons]

If you share verbose build logs, I can try to help troubleshoot what the issue may be.

Root Cause: An error occurred on the service. The package 'olb' with version '1.0.0-win32-984c5e194821b0a3ba02e0e26d88e562352fa3d219498343d64beb0c600fa7e8' in feed 'PipelinesCache' has been deleted.

##[debug]Processed: ##vso[task.issue type=warning;]Error: An unexpected error occurred while trying to download the package. Exit code(1) and error({"@t":"2020-01-29T17:03:57.4212920Z","@m":"ApplicationInsightsTelemetrySender will correlate events with X-TFS-Session 9451ee54-0655-4d4d-af01-452f297b7e4a","@i":"310051b5","SourceContext":"ArtifactTool.Commands.UPackDownloadCommand","UtcTimestamp":"2020-01-29 17:03:57.421Z"}%0D%0A{"@t":"2020-01-29T17:03:57.9655748Z","@m":"An error occurred on the service. The package 'olb' with version '1.0.0-win32-984c5e194821b0a3ba02e0e26d88e562352fa3d219498343d64beb0c600fa7e8' in feed 'PipelinesCache' has been deleted.","@i":"5b6272b8","@l":"Error","SourceContext":"ArtifactTool.Program","UtcTimestamp":"2020-01-29 17:03:57.965Z"})

[ethanis]

Thanks for the logs. Any chance you know how the package was deleted? If you have a package retention setting, it may have been deleted due to policy.

You're correct that CacheRestored should not be true if there is a tar failure - I'll have to investigate why that is happening.

And yes, you are correct that Pipeline Caching is the newer, shinier caching for Azure Pipelines. These tasks (in this repository) are published under the "Microsoft DevLabs" name because they are not officially supported, while the Pipeline Caching tasks are officially owned by the Azure DevOps engineering team.