Commit Graph

21 Commits

Author SHA1 Message Date
Benjamin Sago
93bd052c70 Make Vagrant provisioning quieter and faster
• Install fewer Rust components
• Silence the output of some commands
• Only locale-gen the locales we need, and only do it once

While the 'vagrant up' and 'vagrant provision' times are still very long, and these benchmarks are very variable, there's a noticeable improvement here:

• 'vagrant up' has gone from ~244s to ~223s
• 'vagrant provision' has gone from ~21s to ~7s
2020-10-18 01:19:43 +01:00
Benjamin Sago
d8b21a33b5 More date-related xtests
• Displaying accessed and modified dates
• Displaying dates in the distant past and far future (#557)
2020-10-17 21:26:24 +01:00
Benjamin Sago
ef7bb43dbb Fix xtests bug where git3 file date kept changing 2020-10-17 21:25:49 +01:00
Benjamin Sago
61c5df7c11 Use Specsheet for the extended tests
This commit changes the way the extended test suite is run.

Previously, there was a folder full of outputs, and a script that ran exa repeatedly to check the outputs match. This script was hacked-together, with many problems:

• It stops at the first failure, so if one test fails, you have no idea how many actually failed.
• It also didn't actually show you the diff if one was different, it just checked it.
• It combined stdout and stderr, and didn't test the exit status of exa.
• All the output file names were just whatever I felt like calling the file at the time.
• There is no way to only run a few of the tests — you have to run the whole thing each time.
• There's no feel-good overall view where you see how many tests are passing.

I started writing Specsheet to solve this problem (amongst other problems), and now, three and a half years later, it's finally ready for prime time.

The tests are now defined as data rather than as a script. The outputs have a consistent naming convention (directory_flags.ansitxt), and they check stdout, stderr, and exit status separately. Specsheet also lets simple outputs (empty, non-empty, or one-line error messages) can be written inline rather than needing to be in files.

So even though this pretty much runs the same tests as the run.sh script did, the tests are now more organised, making it easy to see where tests are missing and functionality is not being tested.
2020-10-17 21:12:18 +01:00
Benjamin Sago
91f1541e85 Make the Vagrant environment creation nicer
Now, instead of reams of unreadable command output, we get a nice set of stages:

[ 0/13] Deleting existing test cases directory
[ 1/13] Creating file size testcases
[ 2/13] Creating file name extension testcases
[ 3/13] Creating file names testcases
[ 4/13] Creating special file kind testcases
[ 5/13] Creating symlink testcases
[ 6/13] Creating user and group testcases
[ 7/13] Creating file permission testcases
[ 8/13] Creating date and time testcases
[ 9/13] Creating extended attribute testcases
[10/13] Creating Git testcases (1/3)
[11/13] Creating Git testcases (2/3)
[12/13] Creating Git testcases (3/3)
[13/13] Creating hidden and dot file testcases

The scripts have been moved out of the Vagrantfile because it was getting long and they're more readable this way.
2020-10-16 23:41:25 +01:00
Benjamin Sago
04e2d4c692 Just straight-up roll our own logger
This commit removes the env_logger dependency, replacing it with a simple implementation. Doing so removes like ten other transitive dependencies that no longer need to be included in the build.

It also gains the ability to enable trace-level logging. The users crate, which contains such logging statements as of the version I published a few days ago, has been upgraded to celebrate.

Also, change the log imports to globs. I'm only interested that a file doing logging, not what level it's logging at.
2020-10-10 02:01:12 +01:00
Benjamin Sago
e95eb5e9fc Vagrant changes
• Get rid of the 'fresh' VM. It just got in the way, taking up more memory when 'vagrant up' was used, and only solved one problem  that was happening three years ago when I was at RustFest and in a programm-y mood.
• Use a more up-to-date Ubuntu image and give the machine more cores.
• Start moving some of the developer tools out of this repo. As I get more and more Rust projects, I don't want the scripts to package them to be repeated in each repository.
2020-10-10 00:21:20 +01:00
dalisoft
cf5a9cbf29
build: use binary name only 2020-07-24 09:03:57 +05:00
Benjamin Sago
70606f95ff Change user in Vagrantfile
Why I have to keep doing this I have no idea. If you know, please tell!
2018-09-26 21:25:50 +01:00
Benjamin Sago
d9f6b6e559 Add script to generate checksums 2017-10-08 21:04:34 +01:00
Benjamin Sago
1ebb2e95ff Copy weekly changes into macos script 2017-10-08 20:54:18 +01:00
Benjamin Sago
2e2598c9a0 Rename the zips for weekly releases 2017-10-08 20:53:36 +01:00
Benjamin Sago
431998d0f6 Spiffy up the help text 2017-10-02 10:32:25 +02:00
Benjamin Sago
895808e945 Show friendlier warnings when binaries don’t exist
Also, allow the --release flags to be passed to the build-exa and test-exa commands.
2017-10-02 10:22:50 +02:00
Benjamin Sago
25618ad666 Add a dev help 2017-10-01 12:44:29 +02:00
Benjamin Sago
eb1188c2c8 Give the testing VM commands and help text 2017-10-01 12:37:35 +02:00
Benjamin Sago
a739299583 Add a release-checking script 2017-10-01 12:28:23 +02:00
Benjamin Sago
baccfe544b Linux check for Linux script
These changes are mostly just to mirror the macOS packaging script.
2017-10-01 10:55:38 +02:00
Benjamin Sago
d420d878c5 Add macOS packaging script
This script is a modified version of the Linux one, with a couple of tweaks to get them to look the same (Mach-O strip can’t --verbose?)
2017-10-01 10:55:14 +02:00
Benjamin Sago
a4bd8f7f17 Move the welcoming text to their own files too
Again, it was hard to read and edit this text when it was in a string inside an echo command inside a bash script inside a heredoc inside a Ruby script wrapped in a mystery. It also gives me space to write some actual comments.
2017-10-01 09:49:45 +02:00
Benjamin Sago
173e9b2345 Move the packaging script into its own file
Having it all echo-ed into the file like that made it hard to read *and* hard to maintain. My initial aversion to it was that I didn’t want there to be an executable script in the main repository that only worked when you were in the VM, because people would just run it anyway. But this can be avoided by leaving it non-executable, and having a command in the VM that runs it instead.
2017-10-01 09:48:20 +02:00