Hi @dhadka, happy to further the discussion. Don't mean to hijack the thread, so we could start a different ticket if desired.

Each artifact is tied to a Actions run whereas caches are shared across runs. Unless you setup the cache key to be per-run, you won't necessarily know which CI run created the cache.

We do indeed setup the cache key to be 'per-run' specific, as far as denoting the arch/branch/PR#. Our keys also include a checksum of a reproducible generated lockfile that is derived from a repeatable environmental setup. Lastly we also save including an epoch timestamp that uniquely bumps the cache key as the latest matching key prefix to be restored. Forgive the config syntax, as it's still uses CircleCI, but it demonstrates the use case as described:

Details

        - restore_cache:
            name: Restore Cache << parameters.key >>
            keys:
              - "<< parameters.key >>-v6\
                -{{ arch }}\
                -{{ .Branch }}\
                -{{ .Environment.CIRCLE_PR_NUMBER }}\
                -{{ checksum  \"<< parameters.workspace >>/lockfile.txt\" }}"
              - "<< parameters.key >>-v6\
                -{{ arch }}\
                -main\
                -<no value>\
                -{{ checksum  \"<< parameters.workspace >>/lockfile.txt\" }}"

https://github.com/ros-planning/navigation2/blob/14051a6971efca0aaf51a5ef3df01b24e83b1098/.circleci/config.yml#L33-L45

        - save_cache:
            name: Save Cache << parameters.key >>
            key: "<< parameters.key >>-v6\
              -{{ arch }}\
              -{{ .Branch }}\
              -{{ .Environment.CIRCLE_PR_NUMBER }}\
              -{{ checksum  \"<< parameters.workspace >>/lockfile.txt\" }}\
              -{{ epoch }}"
            paths:
              - << parameters.path >>/.ccache
              - << parameters.path >>/build
              - << parameters.path >>/install
              - << parameters.path >>/log
              - << parameters.path >>/test_results
            when: << parameters.when >>

https://github.com/ros-planning/navigation2/blob/14051a6971efca0aaf51a5ef3df01b24e83b1098/.circleci/config.yml#L59-L73

Note that the list of keys to restore from includes a string variant pointing to main branch as a fallback. This is beneficial in bootstrapping the cache for fresh PRs, and I believe would be just as applicable when opening a codespace for a new branch.

If you're specifically interested in failures, you can conditionally save artifacts. Include the cache, build, and test paths in the upload and you should have everything needed to debug.

Hmm, I was under the impression that artifacts where more for consumable assets, like readable log files or executable binaries; selected and itemized files appropriate for archiving and aggregating a job's results, rather than whole directory trees or recursive folder paths.

For instance, while cache's are inherently intended to be restored over existing filesystems, artifacts don't seem to share that same functional purpose, as there are no similar restore (as opposed to just save) actions for artifacts across multiple paths inplace. I suppose it could be replicated via a prefix and postfix of tarball commands, but it seems silly to re-implement what cache action does here already.

For example, from the snippet above, both the ccache and build directories are included among the cached paths. Both ccache and cmake are notorious in the amount of auto-generated files they produce, easily in the hundreds or thousands; perhaps inappropriate to be individually uploaded as separate artifacts.

Caches are very volatile (due to the 7 days / 10 GB eviction policy) so using it to inspect old CI outputs won't be reliable. Artifacts are retained for 90 days (this is also configurable if you need shorter or longer retention).

I think the limited durability of cache saves is to be expected, especially for free public storage services. If a maintainer follows up on a CI job the next day and can retrieve the cache, that's awesome. But if they stall for more than a week and the cache gets evicted before they respond, then that's on them, with extended cache durability being a justifiable premium feature.

Details

# Release Mode
Found a cache from build 24502 at overlay_ws-v6-arch1-linux-amd64-6_85-main-<no value>-cW3a07dAyXqQu7OKkkuviZJfehF2oGR7lpqfR6kHceI=
Size: 102 MiB
Cached paths:
  * /opt/overlay_ws/.ccache
  * /opt/overlay_ws/build
  * /opt/overlay_ws/install
  * /opt/overlay_ws/log
  * /opt/overlay_ws/test_results

Downloading cache archive...
Validating cache...

Unarchiving cache...

# Debug Mode
Creating cache archive...
Uploading cache archive...
Stored Cache to overlay_ws-v6-arch1-linux-amd64-6_85-main-<no value>-Ftk0f3CMUUeRCCzHcRj723YJ6mLiSIm6zO9hzKWNEpM=-1641677419
  * /opt/overlay_ws/.ccache
  * /opt/overlay_ws/build
  * /opt/overlay_ws/install
  * /opt/overlay_ws/log
  * /opt/overlay_ws/test_results
Total size uploaded: 930 MiB

For example, our cache save size per job is about ~100MiB for Release builds, or ~1GiB for Debug builds (wish I could shrink the latter but the debug symbols for code coverage add a lot to the binaries). We already use a nightly CI job for the main branch, so regardless of the eviction window or capacity, there's usually always a main cache to bootstrap from.

Artifacts has a published API for getting content - https://docs.github.com/en/rest/reference/actions#artifacts
If using the cache, you'd also have to be mindful of partial matches (if using restore-keys).

It would be nice to have such a matching API for caches, but I suppose if one could restore artifacts much in the same manner and ease as caches, then that could alleviate the desire for external cache access. Although, the key look up behavior with caching would still be greatly missed, as it would be wonderful to have the same consistent restoration logic for Codespaces environments as in CI environments. Indexing caches using keys is a proven and accustomed technique for developers, while remaining flexible for most restoration use cases.

Ability to download cache and inspect contents #105

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions