IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* 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
* Allow for multiple line-delimited paths to cache
* Add initial minimatch support
* Use @actions/glob for pattern matching
* Cache multiple entries using --files-from tar input
remove known failing test
Quote tar paths
Add salt to test cache
Try reading input files from manifest
bump salt
Run test on macos
more testing
Run caching tests on 3 platforms
Run tests on self-hosted
Apparently cant reference hosted runners by name
Bump salt
wait for some time after save
more timing out
smarter waiting
Cache in tmp dir that won't be deleted
Use child_process instead of actions/exec
Revert tempDir hack
bump salt
more logging
More console logging
Use filepath to with cacheHttpClient
Test cache restoration
Revert temp dir hack
debug logging
clean up cache.yml testing
Bump salt
change debug output
build actions
* unit test coverage for caching multiple dirs
* Ensure there's a locateable test folder at homedir
* Clean up code
* Version cache with all inputs
* Unit test getCacheVersion
* Include keys in getCacheEntry request
* Clean import orders
* Use fs promises in actionUtils tests
* Update import order for to fix linter errors
* Fix remaining linter error
* Remove platform-specific test code
* Add lerna example for caching multiple dirs
* Lerna example updated to v2
Co-Authored-By: Josh Gross <joshmgross@github.com>
Co-authored-by: Josh Gross <joshmgross@github.com>
Tested this with my own repo which uses a mix of `build.gradle` and `build.gradle.kts` files and this glob seems to be working correctly.
As an aside, please checkout #215 as it would make the process of verifying these globs easier!
* Adding examples for esy as a workflow for OCaml files
* track v1 instead of v1.1.2
Co-Authored-By: Josh Gross <joshmgross@github.com>
* add link in the readme for ocaml-esy
* ocaml -> ocaml/reason
* link in readme says ocaml/reason
Co-authored-by: Josh Gross <joshmgross@github.com>
* Use different IDs for 1) getting the directory of yarn cache 2) the cache itself
Using the current example + https://github.com/actions/cache#skipping-steps-based-on-cache-hit,
I came to a wrong conclusion that I could skip a step
if the `cache-hit` was `true` -
the ID I used was from the wrong step -
the `get yarn cache directory` step,
instead of the `get yarn cache itself` step.
I've updated the example in hopes that it'll be clearer for others aswell!
Signed-off-by: Kipras Melnikovas <kipras@kipras.org>
* Explain which ID to use for `cache-hit` in yarn's example
Signed-off-by: Kipras Melnikovas <kipras@kipras.org>
