more robust circleci testing#6022
Conversation
circle.yml
Outdated
| test: | ||
| override: | ||
| - case $CIRCLE_NODE_INDEX in 0) MODEL=32 ./travis.sh ;; 1) MODEL=64 ./travis.sh ;; esac: | ||
| - case $CIRCLE_NODE_INDEX in 0) MODEL=32 ./circleci.sh ;; 1) MODEL=64 ./circleci.sh ;; esac: |
There was a problem hiding this comment.
@MartinNowak this is a hard-coded hack to support parallelism.
However of course, if only one container is enabled for a repo only the 32-bit will be run.
There was a problem hiding this comment.
It's a horrible YAML abomination b/c apparently they aren't capable to allow hashes as argument (and we don't want to use multiline bash scripts as hash key, even in YAML).
86fc186 to
3809f7c
Compare
- move all the logic into a separate shell script (CircleCI's YAML is really unfriendly for slightly more complicated stuff) - use installer script to fetch bootstrap compiler (same retry logic as on Travis-CI) - cache installed bootstrap compiler
- more consisten with other dmd make options
This reverts commit cffa4c3.
3809f7c to
bdddede
Compare
|
Mainly did this b/c I wanted to restructure the Travis-CI tests to start less workers, but failed due to all the extra cases for CircleCI. |
bdddede to
c842a1c
Compare
Current coverage is 87.42% (diff: 100%)@@ master #6022 diff @@
==========================================
Files 90 90
Lines 55686 55686
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 48459 48681 +222
+ Misses 7227 7005 -222
Partials 0 0
|
| case $CIRCLE_NODE_INDEX in | ||
| 0) MODEL=64 ;; | ||
| 1) MODEL=32 ;; | ||
| esac |
There was a problem hiding this comment.
Could you please enable two containers, s.t. 32-bit gets tested too?
Should be here https://circleci.com/gh/dlang/dmd/edit#parallel-builds
There was a problem hiding this comment.
We're not testing the backend for coverage, shouldn't be much difference, but well.
There was a problem hiding this comment.
I asked @wilzbach to stick with one, because the Terms Of Service only offer 4 instances for open source projects. It was unclear what CircleCI's definition of open source was, so while we await clarification I'd like to stay with one. (If their definition is "public repository", then we're golden.)
There was a problem hiding this comment.
I asked @wilzbach to stick with one, because the Terms Of Service only offer 4 instances for open source projects.
Did you miss this comment?
I just found the following in the settings at the org page
Additionally, projects that are public on GitHub will build with 3 extra containers -- our gift to free and open source software.
and then this in their FAQ
What if I am building open-source?
We offer a total of four free linux containers ($2400 annual value) for open-source projects. Simply keeping your project public will enable this for you!
There was a problem hiding this comment.
I wouldn't think there is any credible risk associated with that, but if it makes you uncomfortable, feel free to just toggle it back in the admin UI (see @wilzbach's link).
If we can get away with only one configuration, this would be preferred either way, though, since parallel PR builds eat into the same allowance.
There was a problem hiding this comment.
@wilzbach yes, I had missed that. Glad this is cleared up. Thanks!
@klickverbot Looks like we're good on that, then. But there's that other issue you mentioned - maybe throttling it by using only 1 instance will be more effective for us than running dry halfway through the month.
There was a problem hiding this comment.
@WalterBright: It's not so much a question of "running dry" than just the latency of parallel builds on many updated PRs.
There was a problem hiding this comment.
than just the latency of parallel builds on many updated PRs.
@klickverbot Let's just see whether it makes a difference and/or clogs our CircleCi queue. It's just an experiment, so we can always switch back to 1 container ;-)
c842a1c to
48e3640
Compare
Thanks a lot for this massive cleanup 👍 |
| local base_branch=$(curl -fsSL https://api.github.com/repos/dlang/dmd/pulls/$CIRCLE_PR_NUMBER | jq -r '.base.ref') | ||
| else | ||
| local base_branch=$CIRCLE_BRANCH | ||
| fi |
There was a problem hiding this comment.
This is the snippet to get the target branch. Hopefully we won't hit any rate limit of github, b/c of other people on the test machine.
There was a problem hiding this comment.
I hope we don't , otherwise we can try 1) direct authenticated access or 2) rolling our own, small API cache
There was a problem hiding this comment.
Or extend CircleCI, but I don't it'll be a problem.
There was a problem hiding this comment.
There was a problem hiding this comment.
Btw didn't you want to merge into the current base_branch?
Something like simple like this should do it?
if [ -n ${CIRCLE_PR_NUMBER:-} ]; then
git remote add upstream git@github.com:dlang/dmd.git
git fetch upstream
git merge "upstream/${base_branch}"
else
git merge ${base_branch}
fi
There was a problem hiding this comment.
Yes merging would be good.
|
Auto-merge toggled on |
|
@MartinNowak This broke building dmd on OS X |
| else | ||
| # Auto-bootstrapping, will download dmd automatically | ||
| HOST_DMD_VER=2.068.2 | ||
| HOST_DMD_VER=2.068.2 # keep in sync with other occurences of that variable, e.g. in circleci.sh |
There was a problem hiding this comment.
That's bash craziness 😢
@JackStouffer do quotes work for you?
There was a problem hiding this comment.
Deleting the space after the 2 and moving the comment to its own line works
There was a problem hiding this comment.
Deleting the space after the 2 and moving the comment to its own line works
How about quickly submitting this as PR? ;-)
No description provided.