Travis CI revamp part 1, refs #2008#2011
Conversation
Revamping Travis and Docker setup introducing a `Makefile`. The idea is to move the CI complexity from .travis.yml to `Makefile`. That makes a single entry point via `make` command and reproducible builds via Docker. It makes it easy to run some commands outside docker, such as: ```sh make testapps/python3/armeabi-v7a ``` Or the same command inside docker: ```sh make docker/run/make/testapps/python3/armeabi-v7a ``` This pull request also starts introducing some docker layer cache optimization as needed by kivy#2009 to speed up docker pull/push and rebuilds from cache. It also introduces other Docker images good practices like ordering dependencies alphabetically or always enforcing `apt update` prior install, refs: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ Subsequent pull requests would simplify the process furthermore and leverage the cache to speed up builds.
a975015 to
c7d76e4
Compare
|
I'm pretty happy with the level of simplification of the |
| # Run a background process to make sure that travis will not kill our tests in | ||
| # case that the travis log doesn't produce any output for more than 10 minutes | ||
| - while sleep 540; do echo "==== Still running (travis, don't kill me) ===="; done & |
There was a problem hiding this comment.
I suspect that we still may need this lines, not for the basic tests we make but for rebuild_updated_recipes whenever we touch some of the most time demanding recipes (icu, boost+libtorrent...). Anyway, we can leave it out, for now, and reintroduce it later in case that we need it...if not...better for us...less code to maintain and more readable.
There was a problem hiding this comment.
Good point for the demanding recipes. Yes I would try without for now as it's more readable, but I can definitely try with some of theses recipes on my fork to see if it builds for too long without providing any output
| --requirements libffi,sdl2,pyjnius,kivy,python3,openssl,requests,sqlite3,setuptools | ||
| --arch=armeabi-v7a | ||
| - <<: *testing | ||
| script: make testapps/python3/armeabi-v7a PYTHON_WITH_VERSION=python3 |
There was a problem hiding this comment.
Do we need to pass PYTHON_WITH_VERSION=python3?
We default to python3, so maybe we can remove it right?
There was a problem hiding this comment.
Good question, on osx I had to put it because the python3.6 binary itself didn't exist, making it fail when generating the virtualenv: virtualenv --python=$(PYTHON_WITH_VERSION) $(VIRTUAL_ENV).
It's just than in osx they don't seem to symlink it
| autoconf \ | ||
| automake \ | ||
| build-essential \ | ||
| ccache \ | ||
| cmake \ | ||
| gettext \ | ||
| git \ | ||
| lbzip2 \ | ||
| libffi-dev \ | ||
| libgtk2.0-0:i386 \ | ||
| libidn11:i386 \ | ||
| libltdl-dev \ | ||
| libncurses5:i386 \ | ||
| libpangox-1.0-0:i386 \ | ||
| libpangoxft-1.0-0:i386 \ | ||
| libstdc++6:i386 \ | ||
| libtool \ | ||
| openjdk-8-jdk \ | ||
| patch \ | ||
| pkg-config \ | ||
| python \ | ||
| python-pip \ | ||
| python3 \ | ||
| python3-dev \ | ||
| python3-pip \ | ||
| python3-venv \ | ||
| sudo \ | ||
| unzip \ | ||
| virtualenv \ | ||
| wget \ | ||
| zip \ | ||
| zlib1g-dev \ | ||
| zlib1g:i386 \ |
There was a problem hiding this comment.
Nice 😄...far more readable sorted and each dependency in one line 👍
There was a problem hiding this comment.
Yes definitely and it's a part of the good practices:
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#sort-multi-line-arguments
| python setup_testapp_python2_sqlite_openssl.py apk --sdk-dir $(ANDROID_SDK_HOME) --ndk-dir $(ANDROID_NDK_HOME) \ | ||
| --requirements sdl2,pyjnius,kivy,python2,openssl,requests,sqlite3,setuptools,numpy |
There was a problem hiding this comment.
Nitpick: I would put each argument in one line, maybe even sorted, as you did with the apt packages (the same for other tests)
There was a problem hiding this comment.
Yes that could make sense too. I'm not sure how the --requirements argument would digest spaces and line breaks between the commas.
I hope you don't mind I try to address this point in subsequent PR as I'm excited for merging this one 😅
opacam
left a comment
There was a problem hiding this comment.
Thanks @AndreMiras, really nice work 👍
Revamping Travis and Docker setup introducing a
Makefile.The idea is to move the CI complexity from .travis.yml to
Makefile.That makes a single entry point via
makecommand and reproduciblebuilds via Docker.
It makes it easy to run some commands outside docker, such as:
Or the same command inside docker:
This pull request also starts introducing some docker layer cache
optimization as needed by #2009 to speed up docker pull/push and
rebuilds from cache.
It also introduces other Docker images good practices like ordering
dependencies alphabetically or always enforcing
apt updatepriorinstall, refs:
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
Subsequent pull requests would simplify the process furthermore and
leverage the cache to speed up builds.