aports/.travis
Jakub Jirutka d903a94387 Revert "travis: require check when not explicitly disabled"
This reverts commit da4e9b11fd.

After 1.5 months it's quite clear that this was a bad idea.

Let me describe a typical situation. Contributor wants to do some small
change in abuild. They did it on their system, it works, so they open a
PR. And it fails on Travis. Why? Because of missing check(), something
totally unrelated to their change! Newbies are often confused. Others
know what to do, but adding check() is often non-trivial. Upstream does
not provide any tests, tests are broken, extra dependencies are needed,
etc. The contributor wanted to do just a small change and now they have
to deal with possibly complicated task. That's not okay.

And the worst is that it caused some devs to ignore CI results. For
example, contributor added php[57] dependency into main/uwsgi. CI failed
due to missing check(). Reviewers did not realized that php[57] is in
the community repository, not main. And some developer merged it despite
CI failed, to revert it few minutes after because it failed on build
servers! This is the exact situation that should be prevented by having
CI.

So, it's a good idea to encourage contributors to add check(), but
eagerly failing build on CI is definitely not a good way.
2017-12-15 15:39:36 +01:00
..
keys travis: add apk key of Alpine's ppc64le builder 2017-10-04 01:12:00 +02:00
abuild-apk Set up Travis to build modified packages 2016-04-05 13:15:19 +00:00
build-pkgs Revert "travis: require check when not explicitly disabled" 2017-12-15 15:39:36 +01:00
common.sh travis: fix issue with FS priviliges after recent update 2017-07-19 22:11:20 +02:00
install-alpine travis: don't download static apk if available on the system 2017-10-04 01:10:17 +02:00
setup-alpine travis: fix issue with FS priviliges after recent update 2017-07-19 22:11:20 +02:00