* Switch from Fedora to Alpine. This makes it possible to have smaller
docker images (Alpine is smaller by itself; apk add --virtual makes it
feasible to correctly remove build dependencies) which will be useful
for caching the images somewhere instead of building them in CI again
and again. This is expected to cut the CI test time in half.
* Make versions of python, vim and vimwiki configurable via docker build
args to enable testing of additional environments. This makes the
build slower, but we will fix that by caching.
Unfortunate consequence of doing all the installs in one RUN step is
that docker build doesn't cache the intermediate steps and therefore
modifying the Dockerfile and testing those modifications locally is now
slower than it used to be. This can likely be improved by using
multi-stage builds (and using BuildKit and its inline cache export to
not break the caching we're about to add a few commits later).
Primary motivation for this is speed: GitHub Actions doesn't limit the
number of concurrent jobs to 4, and also provides a docker registry
(GitHub Packages) that we can use to cache the image (building the image
takes cca 5 minutes, fetching it would take less than 10 seconds). This
is done in another commit.
The workflow definition is a bit more complicated because coveralls
support for GitHub Actions is less mature than for Travis CI, so we need
to manually tell coveralls that all parallel builds have finished and
that it can publish the combined result.
Commit 9f3a52e73b meant to only disable remembering options, but it
ended up disabling remembering of cursor position as well. The cursor is
still restored by last-position-jump (see usr_05.txt) if one has that in
their vimrc, but whenever there are any folds in the view, restoring
these folds resets the cursor again.
Not disabling saving of cursor position fixes this in the default
configuration and lets the user tweak viewoptions however they like.
Did not actually change the code. Instead changed the docs referring to
the "priority" field incorrectly as "pri", and changed `constants.py` to
reflect the correct name for it.
This makes it easier to understand the interaction between the outer and
inner make, as one doesn't need to dig through docker-compose.yml and
possibly Dockerfile to find what command will be run.
It does break the ability to run `docker-compose run --rm tests` but
that's a good thing I believe: I only ever use that when I need a shell
in the container for debugging purposes.
This reverts commit b00e886142.
This fixes reporting of coverage by the few tests that run outside of
vim.
The commit that is being reverted doesn't explain why it was committed,
and the git history suggests it was reverted once and then reintroduced
later again. None of those commits explains the why. I can only guess
that the last time this was committed was an attempt to fix coverage
reporting to outside of docker, which it didn't, and additionally it
made coverage gathering less robust (see previous commit). So this is
yet another fix for the inaccurate coverage reporting.
Or maybe it was because `--cov` without `=taskwiki` an argument reports
coverage for tests instead of taskwiki code? Nevermind, I guess, now it
works well.
Let coverage.py handle generating the filename and saving data at exit.
This is more robust: it adds a random suffix as well so if one process
creates two Coverage objects, they don't write to the same file like we
did. This is another way to fix the inaccurate coverage reporting.
From my experiments it seems that the first Coverage object started (and
thus the last that saves its data) only covers the loading of modules
(defs, classes, etc.) whereas the second one, whose data is overwritten
by the first, contains the actual coverage generated by running the
tests.
Since c8c3cc9a00, vimwiki filetype is set
automatically by :edit, and `set filetype=vimwiki` loads everything
again.
One consequence of loading taskwiki twice is that
taskwiki/testcoverage.py is sourced twice, the Coverage object is
initialized, started, stopped and saved twice (with the same data
filename!) and the coverage report is inaccurate as two trackers write
into the same file.
In markdown, there's no ' =' after '|', so the '+' in the filter regex
doesn't match. Let's allow filter to be empty and distinguish between
viewports and presets using negative look-ahead.
This fixes the failing TestViewportsTaskGenerationEmptyFilter test.
This is a preparation for adding additional commands to the test, like
postprocessing the coverage data, which needs to be processed in the
container (unless we somehow copy the data out of it; but then, we
already install coverage and coveralls inside it, so...).
Additionally, this makes it a bit easier to run the tests locally, which
is helpful when investigating errors. Just a tiny bit, though: it still
requires setting up a fake home with a reasonably minimal .vim and a
python environment with vimrunner.
Not only can we stop ignoring the errors, this also fixes
TestInfoActionNotTriggeredByEnterOnLink which would otherwise cause vim
to complain about g:vimwiki_wikilocal_vars not being available.
Without this, TestInfoActionNotTriggeredByEnterOnLink would pass because
it asserts that the buffer is empty, which is what read_buffer returned
if vim was stuck showing an error message. With `PYTEST_FLAGS=-s`, it
would additionally log
E449: Invalid expression received: Send expression failed.
but that's easy to miss.
`TestSuppressedMapping` leaves vim in visual mode and
`vimrunner.Client.quit()` fails with "E481: No range allowed" resulting
in
Vim: Caught deadly signal TERM
Vim: Finished.
This is probably harmless as the `quit()` is followed by `pkill`, but
let's do it the right way anyway.
Since 8d8fd2c20b, the first `setup`
invocation sets g:taskwiki_markup_syntax="None" which is then detected
in `check_sanity` and vim is restarted, this time with correct
g:taskwiki_markup_syntax. This is wasteful and weird, but makes a bit of
sense as a hack to make `MultiSyntaxIntegrationTest` work as the
test_syntax fixture is not available in `setup`.
To fix this:
* make `teardown` idempotent
* let `check_sanity` fail early if the client is not set up yet
* disable `setup` in `MultiSyntaxIntegrationTest`
* let the sanity check and restart logic handle the setup in
`MultiSyntaxIntegrationTest` once `markup` is available
vimrunner.Server.remote_expr waits for the result so we don't need to
sleep, except perhaps if vim does something asynchronously?
Anyway, this doesn't seem to break any tests here, and is noticeably
faster.
vimrunner.Client.command doesn't do any escaping so we can only use
double quotes. Otherwise it does this:
self.server.remote_expr(["VimrunnerPyEvaluateCommandOutput('let g:vimwiki_list = [{'syntax': 'mediawiki', 'ext': '.txt','path': '/tmp/tmpl1hh2nnf'}]')"])
E449: Invalid expression received: Send expression failed.
We're mounting taskwiki read-only (because the docker container runs as
root) so place the pytest cache elsewhere. This means re-running failed
test isn't possible now. If that is desired, we may run the container as
current user (may require libnss-unknown) instead, later.
This reverts commit 7b823ace5b.
Python in Travis is only used to merge the coverage results (in fact,
not even that, as those results never get out of the docker image), it
doesn't affect the tests in any way.
After updating python to 3.8 the following error pops up when entering
vimwiki:
```
"~/vimwiki/README.md" 63L, 1510C
Error detected while processing ~/dotfiles/vim/bundle/taskwiki/ftplugin/vimwiki/taskwiki.vim:
line 33:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "~/dotfiles/vim/bundle/taskwiki/taskwiki/main.py", line 640, in <module>
WholeBuffer.update_from_tw()
File "~/dotfiles/vim/bundle/taskwiki/taskwiki/errors.py", line 26, in wrapped_function
original_function(*args, **kwargs)
File "~/dotfiles/vim/bundle/taskwiki/taskwiki/decorators.py", line 9, in wrapped_function
vim.command('let save_pos = getpos(".")')
vim.error: Vim:~/dotfiles/vim/bundle/taskwiki/taskwiki/short.py:41: SyntaxWarning: "is not" with a literal. Did you mean "!="?
```
Changing from `is not` to `!=` solves this issue.
