Convert the circle config file to v2 format, as Circle v1 is deprecated#2659
Convert the circle config file to v2 format, as Circle v1 is deprecated#2659dperny merged 1 commit intomoby:masterfrom
Conversation
361f848 to
eef0869
Compare
Codecov Report
@@ Coverage Diff @@
## master #2659 +/- ##
=========================================
- Coverage 61.76% 61.67% -0.1%
=========================================
Files 134 134
Lines 21760 21760
=========================================
- Hits 13440 13420 -20
- Misses 6871 6890 +19
- Partials 1449 1450 +1 |
868c39d to
1da9524
Compare
|
I see CI is green; is this ready for review? |
|
@thaJeztah Yes |
| version: 2 | ||
| jobs: | ||
| build: | ||
| working_directory: ~/go/src/github.com/docker/swarmkit |
There was a problem hiding this comment.
Should this use $GOPATH, or is that not setup when this is used? (otherwise we could use $HOME/go/src/.... for consistency?)
There was a problem hiding this comment.
Unfortunately apparently in the new circle version environment variables aren’t interpolated in the working_directory entry :|
| # Needed to install go | ||
| OS: linux | ||
| ARCH: amd64 | ||
| GOVERSION: 1.10.2 |
| PROTOC: https://github.com/google/protobuf/releases/download/v3.5.0/protoc-3.5.0-linux-x86_64.zip | ||
|
|
||
| # Note(cyli): We create a tmpfs mount to be used for temporary files created by tests | ||
| # to mitigate the excessive I/O latencies that sometimes cause the tests to fail. |
There was a problem hiding this comment.
Is the latency due to files being written in the container's (CoW) filesystem, or just due to physical disk instead of memory (tmpfs) being used? Wondering if a VOLUME /some/path would be resolving the latency sufficiently.
There was a problem hiding this comment.
We did this in CircleCI V1 as well due to those issues, so possibly just whatever is running the CI's disk may be too slow?
| wget -O "$HOME/$(basename $PROTOC)" "$PROTOC" | ||
| unzip -o "$HOME/$(basename $PROTOC)" -d "$HOME" | ||
| sudo cp -R "$HOME/include/google" /usr/local/include | ||
| sudo chmod 777 -R /usr/local/include/google |
There was a problem hiding this comment.
Guess it doesn't matter much, just curious if we know the user that needs access, and if we should make this more granular
There was a problem hiding this comment.
I believe it's just circleci, but I'd rather not have to change this file if CircleCI ever changes that.
|
|
||
| - run: | ||
| name: Push coverage info to codecov.io | ||
| command: bash <(curl -s https://codecov.io/bash) |
| command: | | ||
| sudo rm -rf /usr/local/go | ||
| rm -rf "$GOPATH" | ||
| wget -O "$HOME/go.tar.gz" "https://storage.googleapis.com/golang/go$GOVERSION.$OS-$ARCH.tar.gz" |
There was a problem hiding this comment.
nit: noticed we're using a mixture of wget and curl in this file 😇
|
once merged; this (or a variation on this) should be cherry-picked into the release-branches |
ffae2da to
837577b
Compare
| # One possible hack is the following: | ||
|
|
||
| # /dev/shm in the container is tmpfs although files in /dev/shm are not executable. | ||
| # If we specify TMPDIR=/dev/shm, /dev/shm will be used by our tests, which call |
There was a problem hiding this comment.
This is what I was going to suggest, but it seems you've already tried it.
and will be removed in August 2018. Signed-off-by: Ying Li <ying.li@docker.com>
And will be removed at the end of August: https://circleci.com/blog/sunsetting-1-0/
This also bumps the go version up to 1.10.2, superceding #2636 just because these PRs will otherwise conflict.
Unfortunately when we use the docker executor, the flakiness of our tests are exacerbated so we're using the machine executor for now.