Immediately send CodeCov notifications

[wilzbach]

Apparently CodeCov seems to wait until all CIs have finished:

This is based on a CodeCov issue I found:

https://github.com/codecov/support/issues/312

On the CodeCov side it looks like this:

[dlang-bot]

Thanks for your pull request, @wilzbach!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[wilzbach]

CircleCi error was:

Root package styles references unknown package libdparse
make: *** [../tools/styles/test_extractor] Error 2

That's unfortunately a rather common DUB error, see e.g. dlang/dub#1104

[PetarKirov]

@wilzbach now Circle CI fails with the following:

+ case $1 in
+ echo 'Unknown command'
Unknown command
+ exit 1

./circleci.sh has_public_example returned exit code 1

[wilzbach]

echo 'Unknown command'

Looks like a problem on the CircleCi side (we don't have has_public_example in the circle.yml since a couple of weeks anymore), maybe related to this:

Seems pretty weird in any case ...

[wilzbach]

Seems pretty weird in any case ...

Argh ok. This is due to ffc6ec5 - not sure about a good solution though. We painfully realized that not triggered a hard error on an unknown command isn't smart either (for a couple of weeks the CI didn't ran the commands).
Maybe we can let the dlang-bot rebase PRs automatically (if possible without conflicts).

[wilzbach]

And now DUB fails in the Jenkins tester:

+ dub test --compiler=dmd gfm:opengl
Building package gfm:opengl in /var/lib/jenkins/dlang_projects/d-gamedev-team/gfm/
Memory allocation failed
script returned exit code 2

This madness needs to stop!

[PetarKirov]

Looks like a problem on the CircleCi side (we don't have has_public_example in the circle.yml since a couple of weeks anymore)

We can try disabling & re-enabling CircleCI. Hopefully that would force CircleCI to reload the circle.yml file, which looks like it too aggressively caches.

And now DUB fails in the Jenkins tester

[...]

Memory allocation failed

CC @MartinNowak

The only robust solution for that is to have fallback CI service run the Jenkins tests.