git-testtools - transparent freeze support #384
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes clearer why archives will also be named after the script that created them (even though there is only one version at a time which learns about its version by a special entry in the tar archive)
XZ encoding isn't quite en par yet though.
In future, one could keep an sqlite db around that records the runtime of every run to provide more data on what to do here, like how long these scripts run in total compared to the time it takes to extract archives, for example.
This reverts commit 4f65bf3. It's probably best to simply keep all archives as no matter what, it will be faster and is desirable.
We may create all kinds of strange symlinks for testing.
The directory structure changed, which is now represented in the glob.
cargo nextest runs tests in (even more) parallel which can cause races when creating directories. Usually we could lock with an in-process mutex, but on top of that for these we also have to lock on the file system.
Byron
added a commit
that referenced
this pull request
Apr 14, 2022
Byron
force-pushed
the
test-archive-support
branch
from
705f094 to
1f27237
Compare
For one, it's fast enough. Secondly we want to learn early if something breaks befause git changed. It's likely one will notice that very late as local caches are usually good. Furthermore, what's in the cache might be slightly different in detail.
Byron
added a commit
that referenced
this pull request
Apr 14, 2022
Byron
force-pushed
the
test-archive-support
branch
from
626576b to
4f5b1fd
Compare
This allows access to signal handler setup for example, which can be useful in some situations.
Byron
added a commit
that referenced
this pull request
Apr 15, 2022
Byron
force-pushed
the
test-archive-support
branch
from
1afc947 to
96bb4d4
Compare
This way, linux will always run the scripts, whereas macos and linux can leverage the time savings through extraction.
|
Outcome: Windows tests run 3 minutes faster, and we have archives of all the states generated by git different git versions (but only if we regenerate regularly). Since linux will always run git we will see if something changes that breaks us. |
Byron
added a commit
that referenced
this pull request
Apr 15, 2022
Byron
added a commit
that referenced
this pull request
Apr 15, 2022
Byron
added a commit
that referenced
this pull request
Apr 15, 2022
Byron
added a commit
that referenced
this pull request
Apr 15, 2022
Problem is that these runners are always slow, whereas the ones on windows are only _sometimes_ slow. Generally we don't have to assume installation fails on unix as long as we can build tests, so installing on windows alone should be all that's needed to get relevant coverage.
Byron
added a commit
that referenced
this pull request
Apr 15, 2022
Problem is that these runners are always slow, whereas the ones on windows are only _sometimes_ slow. Generally we don't have to assume installation fails on unix as long as we can build tests, so installing on windows alone should be all that's needed to get relevant coverage.
Byron
added a commit
that referenced
this pull request
Apr 15, 2022
They are built later so that should be redundant, maybe it can save some significant time to skip it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On windows, there is one test in particular which takes more than 60s to prepare the fixture for. It would be great to speed this up by simply untarring the fixture script's output.
To achieve this, one should be able to easily tar up the result of fixture scripts and relate them to the script version that created them (by MD5). These are then added via git-lfs and picked-up automatically if there is an archive with the correct version.
Note that this has to be done selectively or maybe needs some 'smart' fixups after unpacking due to different default config options on different operating systems.
See #382 (comment) for where the idea comes from with some code for untarring archives.
Tasks
allow options to explicitly exclude cache creation for some caches that don't work well for some reason (and remove existing ones)