Closed alerque closed 2 years ago
Is this different that the results you expect locally as of now?
Yes, I would expect 28/30 tests to pass. I would only expect two of the tests in replace.vim
to fail (the two marked "without visual" that run in normal mode).
Here are my local results: https://gist.github.com/telemachus/a0ff1c58a8922175c385384e8575e1ef
That said, I am not sure whether these results reveal deeper problems with the plugin or they are specific to the CI testing environment. Unfortunately, there are a lot of things I'm not familiar with here. Yesterday was the first time I tried vader, and I didn't know that GitHub had its own CI until this morning when I read this! As a comparison, I set up a TravisCI branch on my fork, and tested vim there, and the results are also 28/30. So perhaps the results you're seeing have to do with the GitHub CI setup rather than the plugin or the tests? I probably won't be able to help any further today, but I can check back in over the next few days. Here's the log of the Travis build, if that helps:
https://travis-ci.org/github/telemachus/vim-textobj-quote/builds/693407968#L363
I slapped together a simple .travis.yml
file from vader's suggestion (though it still took me three tries to get it right! too early in the morning for CI build files):
language: vim
before_script: |
git clone https://github.com/junegunn/vader.vim.git
git clone https://github.com/kana/vim-textobj-user.git
script: |
vim -Nu <(cat << VIMRC
filetype off
set rtp+=vader.vim
set rtp+=vim-textobj-user
set rtp+=.
filetype plugin indent on
syntax enable
VIMRC) -c 'Vader! tests/*' > /dev/null
It should be relatively easy to improve that by adding nvim. Also, we should probably use the runner in tests/run
rather than feeding a custom script to travis. That would mean more similarity between local and CI builds.
A final good thing to know about is VADER_OUTPUT_FILE
. If you have that in your environment, then vader will automatically save the output of a test run to a file as well as dump it to the terminal or feed it into {neo,}vim. E.g. VADER_OUTPUT_FILE=$(date '+%Y-%m-%d-%H:%M:%S')-output.txt ./tests/run
will save a datestamped output file in the tests/
directory after a run. That can be useful if you're checking repeatedly with small changes.
Aaa humbug. Apparently the CI work I just did (#33) was something I already did 2 years ago.
And didn't come back to merge.
I had forgotten about this as well.
I see that you had set up vint as well. I don't recall if you did that for the current CI, but I was planning to make changes based on vint next. I'll look at this for ways to add vint to the CI pipeline if it's not already in there.
Vint is in here. I had it in another branch already, but I merged it to this branch and am sorting through what else is in here that should be kept or ditched.
As of now I think I have Vader running properly in CI.
Since you just looked at this, @telemachus do you have any suggestions about the 8 tests failing in VIM and 6 in Neovim? It might have something to do with the Ex (VIM) and headless (Neovim) modes I'm running it in. Is this different that the results you expect locally as of now?