Why:
* Planning on developing a new feature for parsing of stowrc files.
* Need a test harness that performs initialization and clean up
* Initialization: Create directory structure that allows creation of
stowrc files without worrying about squashing existing files.
* Clean up: Remove all files created during testing.
This change addresses the need by:
* Add intialization and cleanup harness in t/rc_options.t
* Define the location to write stowrc files to in $RC_FILE
* Ensures that location $RC_FILE does not already exist.
* Calls the init_test_dirs to bootstrap directory tree.
* After all tests are run, removes $RC_FILE and the testing
directory tree.
* Add basic test of stowrc parsing to t/rc_options.t
* Provides a template of how to create and test a stowrc file.
* Newly created t/rc_options.t file added to MANIFEST
Why:
* Want to add a new feature to parsing of stowrc files.
* Need ability to write .stowrc files for testing without risk of
squashing existing files.
This change addresses the need by:
* Reusing logic in init_test_dirs
* init_test_dirs already creates new directory structure and overwrites
$HOME to point into /tmp.
* This commit changes init_test_dirs to point $HOME at the newly created
directory structure ($OUT_DIR) instead of /tmp.
* Grants ability to write .stowrc to $HOME without fear.
* Pointing $HOME at $OUT_DIR instead of /tmp also makes cleanup easier.
* Remove $OUT_DIR vs remove specific files in /tmp.
Since 2.3.0 is a long overdue release and has many changes,
document them in NEWS in three groups:
- New features / changes in behaviour
- Documentation fixes and enhancements
- Fixes for bugs and technical debt
De-emphasise the package management aspects, since these days
almost everyone prefers to use modern package managers such as
rpm / dpkg / Nix for (system-wide) package management.
Also include more popular modern use cases for Stow such as management
of dotfiles and software compiled in the user's $HOME directory.
Fixes#22: https://github.com/aspiers/stow/issues/22
Unlike the other tests, this actually treats stow(1) as a black box
script, running it directly rather than require-ing it as a library.
This allows us to check things like the exit codes returned.
Charles LeDoux did some awesome work providing this Docker environment
which can test across multiple Perl versions using perlbrew, so it
would be crazy not to use it.
Let's try a new approach where we increment the version number
immediately after publishing a release, not just before.
This will mean that anyone who builds from git gets a version of Stow
which is higher than the release which was just cut, and this could
provide valuable debugging hints in case a bug report does not clearly
state whether the problem arose with the latest release or with a build
from git.
The title of the generated man page was ending up as something like
IO::FILE=IO(0XA719C0)(1)
Also, with newer perls (e.g. v5.22.1), pod2man requires --name if
used within a pipeline.
Closes#18.
https://github.com/aspiers/stow/issues/18
* Use docker to locally run tests on multiple perl versions
* perlbrew used to install multiple perls
* perl environments bootstrapped when image built
* Based on travis configuration
* Adds docker folder to MANIFEST.SKIP
* Running image runs all tests.
* If exit with no error, then all tests pass.
* ./build-docker.sh builds stow testing image.
* ./test-docker.sh runs stow testing image.
* Assumes built with options in build-docker.sh
* *-docker.sh scripts added to MANIFEST.SKIP
