Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make CI faster #587

Merged
merged 5 commits into from
Jun 12, 2018
Merged

Make CI faster #587

merged 5 commits into from
Jun 12, 2018

Conversation

rhysd
Copy link
Contributor

@rhysd rhysd commented Jun 10, 2018

I made running CI faster.

Before: https://travis-ci.org/vim-jp/vital.vim/builds/390362502
After: https://travis-ci.org/rhysd/vital.vim/builds/390389523

Total: 5min 47sec -> 4min 2sec (1min 45sec faster)

Optimizations:

  • Enabled a binary package (bottle) on macOS worker by removing installation options which prevented it. (4m54s -> 2m58s)
    • macOS worker is slow to start. It was a bottleneck.
    • Removed Lua dependency since Lua was not actually used in CI. (--with-lua could be omitted by this change)
    • Link vim executable directly (--with-override-system-vim could be omitted by this change)
  • Separate running linters into another job.
    • Since it took 200s.
    • After optimizing macOS worker, the job which run linters was a bottleneck.

I assigned people as reviewers who would be familiar with

  • CI scripts
  • macOS

Fix #534

rhysd added 3 commits June 10, 2018 22:11
because it is not necessary for running CI
Removing --with-override-system-vim can install MacVim with a binary
package (bottle).
because running linters takes the longest time among CI jobs
@ujihisa
Copy link
Member

ujihisa commented Jun 10, 2018

Great work! I'll leave proper review for someone who knows CIs better than me, but I like these changes 👍

Removed Lua dependency since Lua was not actually used in CI. (--with-lua could be omitted by this change)

Good catch! 👍

@ujihisa ujihisa removed their request for review June 10, 2018 13:30
@rhysd
Copy link
Contributor Author

rhysd commented Jun 10, 2018

@ujihisa Thank you. I assigned you since you're more familiar with macOS than me. From macOS (Homebrew) user point of view, I'd be happy if you check the changes.

@ujihisa
Copy link
Member

ujihisa commented Jun 10, 2018

(I used to be a professional MacVim user. Currently I have no MacBooks/iMacs...)

- covimerage write_coverage $THEMIS_PROFILE
- coverage xml
- bash <(curl -s https://codecov.io/bash)
- bash scripts/coverage.sh
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[optional] i slightly prefer moving this line after themis line.
it doesn't need to be run with RUN_LINT=true, so it's a bit confusing.

Copy link
Contributor Author

@rhysd rhysd Jun 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me confirm: 'themis line' means the line which runs unit tests with themis.vim, am I correct?

If so, we can't move this line to script section because coverage should be taken only if CI was successfully done.
The guard $RUN_LINT == "" is in coverage.sh, but separating scripts into another file may make understanding what is done harder.
Do you think we should write the script directly in .travis.yml as follows?

- |
    if [[ "${RUN_LINT}" == "" ]]; then
      covimerage write_coverage $THEMIS_PROFILE
      coverage xml
      bash <(curl -s https://codecov.io/bash)
    fi

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cannot we run like this?
Another option is use && to run coverage scripts.

-  if [[ "${RUN_LINT}" != "true" ]]; then
     /tmp/vim-themis/bin/themis --runtimepath /tmp/vimproc --exclude ConcurrentProcess --reporter dot
     bash scripts/coverage.sh
   fi

One additional good point to do this is that we can upload coverage scripts when another commands failed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also ok. I'll choose it. Thank you for your advice.

Copy link
Contributor Author

@rhysd rhysd Jun 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that the fix for this causes some problem on macOS: https://travis-ci.org/vim-jp/vital.vim/jobs/391106600
I don't have enough time to investigate so let me skip this for now (since it's just an option).

git clone --depth 1 --branch "${VIM_VERSION}" https://github.com/vim/vim /tmp/vim
cd /tmp/vim
./configure --prefix="${HOME}/vim" --with-features=huge \
--enable-perlinterp --enable-pythoninterp --enable-python3interp \
--enable-rubyinterp --enable-luainterp --enable-fail-if-missing
--enable-rubyinterp --enable-fail-if-missing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just curious how it would speed up if --enable-rubyinterp was removed,
if it is not too much to ask...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not consider that. Let me try.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tyru I tried removing if_perl and if_ruby, but could not see performance improvements https://travis-ci.org/rhysd/vital.vim/builds/390581618

Copy link
Member

@tyru tyru Jun 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rhysd Thanks!!
Then I think if_perl and if_ruby should be left.

Copy link
Member

@tyru tyru Jun 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmmmm, @lambdalisue told me that if_perl and if_ruby sometimes causes build error... (on vim-jp #vital-dev slack)
So now I feel removing language interfaces as possible is the right policy then...
Now I remember language interfaces sometimes doesn't follow the latest language's change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, fixed.
❌ if_perl and if_ruby causes build error
⭕ if_perl and if_ruby sometimes causes build error

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think --enable-luainterp should be removed while some codes in vital.vim relies on that feature.
https://github.com/vim-jp/vital.vim/search?p=1&q=lua&unscoped_q=lua

I'm very welcome to remove --enable-rubyinterp or --enable-perlinterp while no codes in vital.vim uses that features and it sometime cause build errors.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think vital needs +lua/dyn for Text/Sexp

@lambdalisue
Copy link
Member

Note: It's a bit beyond this PR but I've found that using Docker is quite useful to test on Linux.

https://github.com/lambdalisue/gina.vim/blob/master/.travis.yml#L40-L43

@rhysd
Copy link
Contributor Author

rhysd commented Jun 11, 2018

Note: It's a bit beyond this PR but I've found that using Docker is quite useful to test on Linux.

Definitely. Moving to Docker container might be a future work to improve this further.

git clone --depth 1 --branch "${VIM_VERSION}" https://github.com/vim/vim /tmp/vim
cd /tmp/vim
./configure --prefix="${HOME}/vim" --with-features=huge \
--enable-perlinterp --enable-pythoninterp --enable-python3interp \
--enable-rubyinterp --enable-luainterp --enable-fail-if-missing
--enable-rubyinterp --enable-fail-if-missing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think --enable-luainterp should be removed while some codes in vital.vim relies on that feature.
https://github.com/vim-jp/vital.vim/search?p=1&q=lua&unscoped_q=lua

I'm very welcome to remove --enable-rubyinterp or --enable-perlinterp while no codes in vital.vim uses that features and it sometime cause build errors.

brew install macvim
# Instead of --with-override-system-vim, manually link the executable because
# it prevents MacVim installation with a bottle.
ln -s "$(brew --prefix macvim)/bin/mvim" "/usr/local/bin/vim"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about

export THEMIS_VIM="$(brew --prefix macvim)/bin/mvim"

instead?

@lambdalisue
Copy link
Member

lambdalisue commented Jun 11, 2018

Outdated but

  1. I think --enable-luainterp should be kept Let's ignore.
  2. I prefer export THEMIS_VIM=$(brew ...) instead (nit)

@rhysd
Copy link
Contributor Author

rhysd commented Jun 11, 2018

@lambdalisue @raa0121

I think --enable-luainterp should be kept

Test using Lua is only Text/Sexp.vim (which has only one test case). Other modules which use Lua don't have any tests. So it's a trade-off. 'Give up one test case for Text/Sexp.vim' v.s. 'Making CI faster (about 1.4x faster)'. I don't have any strong opinion for this, actually.

@ujihisa
Copy link
Member

ujihisa commented Jun 11, 2018

Please ignore Text.Sexp. I'm planning to deprecate its lua version, along with #582 (Text.Sexp and brainf**k modules depended on it)

(I'll make another pullreq to deprecate them.)

@tyru
Copy link
Member

tyru commented Jun 11, 2018

👍 for ignore

@ujihisa
Copy link
Member

ujihisa commented Jun 11, 2018

👏 let's merge 👏

@tyru
Copy link
Member

tyru commented Jun 11, 2018

Still remaining issue exists #587 (comment)

@ujihisa ujihisa mentioned this pull request Jun 11, 2018
@rhysd rhysd force-pushed the ci/make-faster branch 4 times, most recently from d5c6616 to 4e9a28e Compare June 12, 2018 05:48
@rhysd
Copy link
Contributor Author

rhysd commented Jun 12, 2018

@tyru @ujihisa @haya14busa @lambdalisue @raa0121 @thinca Thank you for your reviews

@rhysd rhysd merged commit f4fca8c into vim-jp:master Jun 12, 2018
@rhysd rhysd deleted the ci/make-faster branch June 12, 2018 05:56
@tyru
Copy link
Member

tyru commented Jun 12, 2018

🎉🎉🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants