* Add "see more" link to GHE-not-supported warning
I lived for several months thinking that support for caching action on GHE is just a matter of time, because it's such an important thing to have. Only today, I discovered that originally it was not planned at all. And that people already created some workarounds. So I hope that linking the issue from the warning message will save other people from what happened to me :-)
* Update new GHE-not-supported message in tests
* Update generated dist files
* Fix bugs in example of how to use with pipenv
The current example of how to use `@actions/cache` with pipenv has two
problems:
1. The cached virtualenv that pipenv creates has `bin/python` as a symlink
into paths like `/opt/hostedtoolcache/Python/3.7.11` that explicitly
include the patch version of python. When the cache is restored onto a
machine running a slightly different version of python, e.g., when
GitHub upgrades its runners from python 3.7.10 to 3.7.11, then any
attempt to run python in the workflow mysteriously fails with errors
like `Failed to load paths: /bin/sh: 1: /home/runner/.local/share/virtualenvs/myrepo-sOIMCiTO/bin/python: not found`.
Therefore the patch version of python should be included in the cache
key.
2. `pipenv --install` has the unfortunate behaviour of not cleaning out
any pre-existing packages. That is, if the `Pipfile` first contains
dependencies on `foo` and `bar`, and then you remove `bar` from the
`Pipfile` and run `pipenv install` again, `bar` is still included in
the virtualenv.
This can cause false-positive test failures: when a dependency is
removed from the `Pipfile` but there is still code that relies on the
removed dependency, tests can still pass if the dependency comes from
the cache based on a previous revision of `Pipfile.lock`.
Therefore `restore-keys` should not be set.
This PR attempts to address both of these issues.
* Explain why setup-python is included in example
pip's documentation explicitly states to not use `import pip`:
> While it is implemented in Python, and so is available from your Python code via
> `import pip`, you must not use pip’s internal APIs in this way.
This example is in direct contradiction with the documentation's guidance and, thus, has
been removed.
Manually caching gems has many issues:
* Not working if there is no Gemfile.lock but only a Gemfile
* Not having the OS version in the key, which might cause binary incompatibility with system libraries of different ABI version.
* Not taking the Ruby version in account.
* Not taking the Ruby ABI version of development builds into accounts, which cannot be done with a key, but needs the commit hash.
* Using restore-keys would grow the cache over time and have extra gems in the cache.
* Those reasons are summarized in https://github.com/marketplace/actions/setup-ruby-jruby-and-truffleruby#caching-bundle-install-manually
stale-issue-message:"This issue is stale because it has been open for 365 days with no activity. Leave a comment to avoid closing this issue in 5 days."
close-issue-message:"This issue was closed because it has been inactive for 5 days since being marked as stale."
