Llewellyn/exa
1
0
Fork 0
mirror of https://github.com/Llewellynvdm/exa.git synced 2024-12-29 11:02:39 +00:00
Code Issues Projects Releases Wiki Activity
098788c98e
exa/Vagrantfile

419 lines
16 KiB
Ruby
Raw Normal View History

Fix Vagrantfile
2017-04-29 21:53:47 +00:00
require 'date'
Switch to an Ubuntu Vagrant image The non-contrib Debian one doesn’t come with guest additions, meaning it used rsync instead of Virtualbox shared folders to sync files, meaning edits made in the VM didn’t get propogated back to the host, meaning I got very confused for a while. Thanks to the parent commit, this shouldn’t be an issue at all: the default user name, which is now “ubuntu” instead of “vagrant” is specified in a lot fewer places, making it much easier to change.
2017-04-28 18:36:42 +00:00
Vagrant.configure(2) do |config|
config.vm.provider :virtualbox do |v|
v.name = 'exa'
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
v.memory = 1024
v.cpus = 1
end
Convert the aliases to actual files
2017-05-06 18:38:34 +00:00
developer = 'ubuntu'
Switch to an Ubuntu Vagrant image The non-contrib Debian one doesn’t come with guest additions, meaning it used rsync instead of Virtualbox shared folders to sync files, meaning edits made in the VM didn’t get propogated back to the host, meaning I got very confused for a while. Thanks to the parent commit, this shouldn’t be an issue at all: the default user name, which is now “ubuntu” instead of “vagrant” is specified in a lot fewer places, making it much easier to change.
2017-04-28 18:36:42 +00:00
# We use Ubuntu instead of Debian because the image comes with two-way
# shared folder support by default.
config.vm.box = 'ubuntu/xenial64'
config.vm.hostname = 'exa'
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Make the Vagrant provisioning process quieter
2017-04-30 10:06:52 +00:00
# Install the dependencies needed for exa to build, as quietly as
# apt can do.
Fish completions
2017-05-06 19:34:59 +00:00
config.vm.provision :shell, privileged: true, inline: <<-EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
set -xe
Fish completions
2017-05-06 19:34:59 +00:00
apt-get install -qq -o=Dpkg::Use-Pty=0 -y \
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
git cmake curl attr libgit2-dev \
Bash completions
2017-05-06 20:56:40 +00:00
fish zsh bash bash-completion
Fish completions
2017-05-06 19:34:59 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Guarantee that the timezone is UTC -- some of the tests
# depend on this (for now).
config.vm.provision :shell, privileged: true, inline:
%[timedatectl set-timezone UTC]
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Install Rust.
# This is done as vagrant, not root, because it’s vagrant
# who actually uses it. Sent to /dev/null because the progress
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# bar produces a ton of output.
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
config.vm.provision :shell, privileged: false, inline:
%[hash rustc &>/dev/null || curl -sSf https://static.rust-lang.org/rustup.sh | sh &> /dev/null]
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Use a different ‘target’ directory on the VM than on the host.
# By default it just uses the one in /vagrant/target, which can
# cause problems if it has different permissions than the other
# directories, or contains object files compiled for the host.
Give everybody dexa and rexa aliases Also, make it so the same line doesn’t get added to the .bashrc every time provisioning is run.
2017-05-06 18:07:29 +00:00
config.vm.provision :shell, privileged: false, inline: <<-EOF
function put_line() {
grep -q -F "$2" $1 || echo "$2" >> $1
}
Fish completions
2017-05-06 19:34:59 +00:00
put_line ~/.bashrc 'export CARGO_TARGET_DIR=/home/#{developer}/target'
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
put_line ~/.bashrc 'export PATH=$PATH:/home/#{developer}/.cargo/bin'
Fish completions
2017-05-06 19:34:59 +00:00
EOF
# Create "dexa" and "rexa" scripts that run the debug and release
# compiled versions of exa.
config.vm.provision :shell, privileged: true, inline: <<-EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
set -xe
Rename dexa to just exa
2017-05-06 19:52:43 +00:00
echo -e "#!/bin/sh\n/home/#{developer}/target/debug/exa \\$*" > /usr/bin/exa
Remember to pass arguments in dexa and rexa
2017-05-06 19:50:47 +00:00
echo -e "#!/bin/sh\n/home/#{developer}/target/release/exa \\$*" > /usr/bin/rexa
Rename dexa to just exa
2017-05-06 19:52:43 +00:00
chmod +x /usr/bin/{exa,rexa}
Give everybody dexa and rexa aliases Also, make it so the same line doesn’t get added to the .bashrc every time provisioning is run.
2017-05-06 18:07:29 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Fish completions
2017-05-06 19:34:59 +00:00
# Link the completion files so they’re “installed”.
config.vm.provision :shell, privileged: true, inline: <<-EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
set -xe
Bash completions
2017-05-06 20:56:40 +00:00
test -h /etc/bash_completion.d/exa \
|| ln -s /vagrant/contrib/completions.bash /etc/bash_completion.d/exa
Zsh completions
2017-05-06 19:50:24 +00:00
test -h /usr/share/zsh/vendor-completions/_exa \
|| ln -s /vagrant/contrib/completions.zsh /usr/share/zsh/vendor-completions/_exa
test -h /usr/share/fish/completions/exa.fish \
Fish completions
2017-05-06 19:34:59 +00:00
|| ln -s /vagrant/contrib/completions.fish /usr/share/fish/completions/exa.fish
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# We create two users that own the test files.
Convert the aliases to actual files
2017-05-06 18:38:34 +00:00
# The first one just owns the ordinary ones, because we don’t want the
# test outputs to depend on “vagrant” or “ubuntu” existing.
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
user = "cassowary"
config.vm.provision :shell, privileged: true, inline:
%[id -u #{user} &>/dev/null || useradd #{user}]
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# The second one has a long name, to test that the file owner column
# widens correctly. The benefit of Vagrant is that we don’t need to
# set this up on the *actual* system!
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
longuser = "antidisestablishmentarienism"
config.vm.provision :shell, privileged: true, inline:
%[id -u #{longuser} &>/dev/null || useradd #{longuser}]
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Protect xtests against the passage of time There was a problem with the Vagrant tests where the year 2016 was hard-coded in as the modified date. This had to be done to make the --long tests use the correct date format, which varies depending on whether the timestamp is in the current year. Unfortunately, time progresses [citation needed], and what was once 2016 is now 2017, so the date format changed and the tests broke. Because the Vagrantfile is just a Ruby script, we can look up the current year at runtime and use that instead. There’s also a check added to the test runner that makes sure none of the files are more than 365 days old, because if any are, then it’s time to update the timestamps (or it’s the last day of a leap year)
2017-04-28 18:26:57 +00:00
# Because the timestamps are formatted differently depending on whether
# they’re in the current year or not (see `details.rs`), we have to make
# sure that the files are created in the current year, so they get shown
# in the format we expect.
current_year = Date.today.year
some_date = "#{current_year}01011234.56" # 1st January, 12:34:56
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# We also need an UID and a GID that are guaranteed to not exist, to
# test what happen when they don’t.
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
invalid_uid = 666
invalid_gid = 616
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# Delete old testcases if they exist already, then create a
# directory to house new ones.
test_dir = "/testcases"
config.vm.provision :shell, privileged: true, inline: <<-EOF
set -xe
rm -rfv #{test_dir}
mkdir #{test_dir}
chmod 777 #{test_dir}
EOF
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Awkward file size testcases.
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# This needs sudo to set the files’ users at the very end.
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/files"
for i in {1..13}; do
fallocate -l "$i" "#{test_dir}/files/$i"_bytes
fallocate -l "$i"KiB "#{test_dir}/files/$i"_KiB
fallocate -l "$i"MiB "#{test_dir}/files/$i"_MiB
done
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
touch -t #{some_date} "#{test_dir}/files/"*
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
chmod 644 "#{test_dir}/files/"*
sudo chown #{user}:#{user} "#{test_dir}/files/"*
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
# File name extension testcases.
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
# These aren’t tested in details view, but we set timestamps on them to
# test that various sort options work.
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
mkdir "#{test_dir}/file-names-exts"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/Makefile"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/IMAGE.PNG"
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/image.svg"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/VIDEO.AVI"
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/video.wmv"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/music.mp3"
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/MUSIC.OGG"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/lossless.flac"
touch "#{test_dir}/file-names-exts/lossless.wav"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/crypto.asc"
touch "#{test_dir}/file-names-exts/crypto.signature"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/document.pdf"
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/DOCUMENT.XLSX"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Upcase some of the extension testcases These are going to be used for sort testing. Unfortunately, three existing tests that were using the lowercase versions had to be changed.
2017-06-29 12:57:31 +00:00
touch "#{test_dir}/file-names-exts/COMPRESSED.ZIP"
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/compressed.tar.gz"
touch "#{test_dir}/file-names-exts/compressed.tgz"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/backup~"
touch "#{test_dir}/file-names-exts/#SAVEFILE#"
touch "#{test_dir}/file-names-exts/file.tmp"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
touch "#{test_dir}/file-names-exts/compiled.class"
touch "#{test_dir}/file-names-exts/compiled.o"
touch "#{test_dir}/file-names-exts/compiled.js"
touch "#{test_dir}/file-names-exts/compiled.coffee"
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Add some awkward file name testcases
2017-05-01 11:22:57 +00:00
# File name testcases.
# bash really doesn’t want you to create a file with escaped characters
# in its name, so we have to resort to the echo builtin and touch!
#
# The double backslashes are not strictly necessary; without them, Ruby
# will interpolate them instead of bash, but because Vagrant prints out
# each command it runs, your *own* terminal will go “ding” from the alarm!
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/file-names"
echo -ne "#{test_dir}/file-names/ascii: hello" | xargs -0 touch
echo -ne "#{test_dir}/file-names/emoji: [🆒]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/utf-8: pâté" | xargs -0 touch
echo -ne "#{test_dir}/file-names/bell: [\\a]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/backspace: [\\b]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/form-feed: [\\f]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/new-line: [\\n]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/return: [\\r]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/tab: [\\t]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/vertical-tab: [\\v]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/escape: [\\033]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/ansi: [\\033[34mblue\\033[0m]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/invalid-utf8-1: [\\xFF]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/invalid-utf8-2: [\\xc3\\x28]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/invalid-utf8-3: [\\xe2\\x82\\x28]" | xargs -0 touch
echo -ne "#{test_dir}/file-names/invalid-utf8-4: [\\xf0\\x28\\x8c\\x28]" | xargs -0 touch
Also escape characters in links and headings Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module. This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
2017-05-01 20:54:53 +00:00
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]" | xargs -0 mkdir
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]/subfile" | xargs -0 touch
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]/another: [\\n]" | xargs -0 touch
Also escape characters in broken symlinks
2017-05-02 07:46:43 +00:00
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]/broken" | xargs -0 touch
Also escape characters in links and headings Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module. This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
2017-05-01 20:54:53 +00:00
mkdir "#{test_dir}/file-names/links"
ln -s "#{test_dir}/file-names/new-line-dir"*/* "#{test_dir}/file-names/links"
Also escape characters in broken symlinks
2017-05-02 07:46:43 +00:00
echo -ne "#{test_dir}/file-names/new-line-dir: [\\n]/broken" | xargs -0 rm
Add some awkward file name testcases
2017-05-01 11:22:57 +00:00
EOF
Start adding some special file testcases
2017-04-28 22:24:19 +00:00
# Special file testcases.
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/specials"
sudo mknod "#{test_dir}/specials/block-device" b 3 60
sudo mknod "#{test_dir}/specials/char-device" c 14 40
sudo mknod "#{test_dir}/specials/named-pipe" p
Tests for classify and special file types
2017-04-29 08:21:31 +00:00
sudo touch -t #{some_date} "#{test_dir}/specials/"*
Start adding some special file testcases
2017-04-28 22:24:19 +00:00
EOF
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Awkward symlink testcases.
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/links"
Add tests for relative symlinks
2017-04-30 10:58:29 +00:00
ln -s / "#{test_dir}/links/root"
ln -s /usr "#{test_dir}/links/usr"
ln -s nowhere "#{test_dir}/links/broken"
Add some symlink testcases
2016-10-29 18:58:34 +00:00
ln -s /proc/1/root "#{test_dir}/links/forbidden"
Add tests for relative symlinks
2017-04-30 10:58:29 +00:00
touch "#{test_dir}/links/some_file"
ln -s "#{test_dir}/links/some_file" "#{test_dir}/links/some_file_absolute"
(cd "#{test_dir}/links"; ln -s "some_file" "some_file_relative")
(cd "#{test_dir}/links"; ln -s "." "current_dir")
(cd "#{test_dir}/links"; ln -s ".." "parent_dir")
(cd "#{test_dir}/links"; ln -s "itself" "itself")
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Awkward passwd testcases.
# sudo is needed for these because we technically aren’t a member
# of the groups (because they don’t exist), and chown and chgrp
# are smart enough to disallow it!
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/passwd"
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
touch -t #{some_date} "#{test_dir}/passwd/unknown-uid"
chmod 644 "#{test_dir}/passwd/unknown-uid"
sudo chown #{invalid_uid}:#{user} "#{test_dir}/passwd/unknown-uid"
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
touch -t #{some_date} "#{test_dir}/passwd/unknown-gid"
chmod 644 "#{test_dir}/passwd/unknown-gid"
sudo chown #{user}:#{invalid_gid} "#{test_dir}/passwd/unknown-gid"
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Awkward permission testcases.
xtests for higher order bits Finally, re-do the permissions extended tests to include the setuid, setgid, and sticky bits, and rename the last two existing ones to match the others (files with the same names as their permissions).
2017-05-30 14:32:11 +00:00
# Differences in the way ‘chmod’ handles setting ‘setuid’ and ‘setgid’
# when you don’t already own the file mean that we need to use ‘sudo’
# to change permissions to those.
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/permissions"
xtests for higher order bits Finally, re-do the permissions extended tests to include the setuid, setgid, and sticky bits, and rename the last two existing ones to match the others (files with the same names as their permissions).
2017-05-30 14:32:11 +00:00
mkdir "#{test_dir}/permissions/forbidden-directory"
chmod 000 "#{test_dir}/permissions/forbidden-directory"
touch -t #{some_date} "#{test_dir}/permissions/forbidden-directory"
sudo chown #{user}:#{user} "#{test_dir}/permissions/forbidden-directory"
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
xtests for higher order bits Finally, re-do the permissions extended tests to include the setuid, setgid, and sticky bits, and rename the last two existing ones to match the others (files with the same names as their permissions).
2017-05-30 14:32:11 +00:00
for perms in 000 001 002 004 010 020 040 100 200 400 644 755 777 1000 1001 2000 2010 4000 4100 7666 7777; do
touch "#{test_dir}/permissions/$perms"
sudo chown #{user}:#{user} "#{test_dir}/permissions/$perms"
sudo chmod $perms "#{test_dir}/permissions/$perms"
sudo touch -t #{some_date} "#{test_dir}/permissions/$perms"
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
done
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
# Awkward extended attribute testcases.
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/attributes"
touch "#{test_dir}/attributes/none"
touch "#{test_dir}/attributes/one"
setfattr -n user.greeting -v hello "#{test_dir}/attributes/one"
touch "#{test_dir}/attributes/two"
setfattr -n user.greeting -v hello "#{test_dir}/attributes/two"
setfattr -n user.another_greeting -v hi "#{test_dir}/attributes/two"
#touch "#{test_dir}/attributes/forbidden"
#setfattr -n user.greeting -v hello "#{test_dir}/attributes/forbidden"
#chmod +a "$YOU deny readextattr" "#{test_dir}/attributes/forbidden"
mkdir "#{test_dir}/attributes/dirs"
mkdir "#{test_dir}/attributes/dirs/empty-with-attribute"
setfattr -n user.greeting -v hello "#{test_dir}/attributes/dirs/empty-with-attribute"
mkdir "#{test_dir}/attributes/dirs/full-with-attribute"
touch "#{test_dir}/attributes/dirs/full-with-attribute/file"
setfattr -n user.greeting -v hello "#{test_dir}/attributes/dirs/full-with-attribute"
mkdir "#{test_dir}/attributes/dirs/full-but-forbidden"
touch "#{test_dir}/attributes/dirs/full-but-forbidden/file"
#setfattr -n user.greeting -v hello "#{test_dir}/attributes/dirs/full-but-forbidden"
#chmod 000 "#{test_dir}/attributes/dirs/full-but-forbidden"
#chmod +a "$YOU deny readextattr" "#{test_dir}/attributes/dirs/full-but-forbidden"
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
touch -t #{some_date} "#{test_dir}/attributes"
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
touch -t #{some_date} "#{test_dir}/attributes/"*
touch -t #{some_date} "#{test_dir}/attributes/dirs/"*
touch -t #{some_date} "#{test_dir}/attributes/dirs/"*/*
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
sudo chown #{user}:#{user} -R "#{test_dir}/attributes"
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
Add xtests for existing Git implementation
2017-05-17 08:17:12 +00:00
# A sample Git repository
# This uses cd because it's easier than telling Git where to go each time
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
mkdir "#{test_dir}/git"
cd "#{test_dir}/git"
git init
mkdir edits additions moves
echo "original content" | tee edits/{staged,unstaged,both}
echo "this file gets moved" > moves/hither
git add edits moves
git commit -m "Automated test commit"
echo "modifications!" | tee edits/{staged,both}
touch additions/{staged,edited}
mv moves/{hither,thither}
git add edits moves additions
echo "more modifications!" | tee edits/unstaged edits/both additions/edited
touch additions/unstaged
touch -t #{some_date} "#{test_dir}/git/"*/*
sudo chown #{user}:#{user} -R "#{test_dir}/git"
EOF
Override the names of . and .. There was a problem when displaying . and .. in directory listings: their names would normalise to actual names! So instead of literally seeing `.`, you’d see the current directory’s name, inserted in sort order into the list of results. Obviously this is not what we want. In unrelated news, putting `.` and `..` into the list of paths read from a directory just takes up more heap space for something that’s basically constant. We can solve both these problems at once by moving the DotFilter to the files iterator in Dir, rather than at the Dir’s creation. Having the iterator know whether it should display `.` and `..` means it can emit those files first, and because it knows what those files really represent, it can override their file names to actually be those sequences of dots. This is not a perfect solution: the main casualty is that a File can now be constructed with a name, some metadata, both, or neither. This is currently handled with a bunch of Options, and returns IOResult even without doing any IO operations. But at least all the tests pass!
2017-06-28 17:41:31 +00:00
# Hidden and dot file testcases.
# We need to set the permissions of `.` and `..` because they actually
# get displayed in the output here, so this has to come last.
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
shopt -u dotglob
GLOBIGNORE=".:.."
mkdir "#{test_dir}/hiddens"
touch "#{test_dir}/hiddens/visible"
touch "#{test_dir}/hiddens/.hidden"
touch "#{test_dir}/hiddens/..extra-hidden"
# ./hiddens/
touch -t #{some_date} "#{test_dir}/hiddens/"*
chmod 644 "#{test_dir}/hiddens/"*
sudo chown #{user}:#{user} "#{test_dir}/hiddens/"*
# .
touch -t #{some_date} "#{test_dir}/hiddens"
chmod 755 "#{test_dir}/hiddens"
sudo chown #{user}:#{user} "#{test_dir}/hiddens"
# ..
sudo touch -t #{some_date} "#{test_dir}"
sudo chmod 755 "#{test_dir}"
sudo chown #{user}:#{user} "#{test_dir}"
EOF
Add thing for installing cargo-kcov
2017-05-07 19:25:53 +00:00
# Install kcov for test coverage
# This doesn’t run coverage over the xtests so it’s less useful for now
if ENV.key?('INSTALL_KCOV')
config.vm.provision :shell, privileged: false, inline: <<-EOF
set -xe
test -e ~/.cargo/bin/cargo-kcov \
|| cargo install cargo-kcov
sudo apt-get install -qq -o=Dpkg::Use-Pty=0 -y \
cmake g++ pkg-config \
libcurl4-openssl-dev libdw-dev binutils-dev libiberty-dev
cargo kcov --print-install-kcov-sh | sudo sh
EOF
end
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
end
Reference in New Issue Copy Permalink