-
-
Save ryboe/df2dab474520c4086926f672c52db139 to your computer and use it in GitHub Desktop.
# use the latest ubuntu environment (18.04) available on travis | |
dist: bionic | |
language: go | |
# You don't need to test on very old versions of the Go compiler. It's the user's | |
# responsibility to keep their compiler up to date. | |
go: | |
- 1.16.x | |
# Only clone the most recent commit. | |
git: | |
depth: 1 | |
# Skip the install step. Don't `go get` dependencies. Only build with the code | |
# in vendor/ | |
install: true | |
# Don't email me the results of the test runs. | |
notifications: | |
email: false | |
# Anything in before_script that returns a nonzero exit code will flunk the | |
# build and immediately stop. It's sorta like having set -e enabled in bash. | |
# We can download and extract the golangci-lint binary in one (long) command. | |
before_script: | |
- curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.37.1 | |
# script always runs to completion (set +e). If we have linter issues AND a | |
# failing test, we want to see both. Configure golangci-lint with a | |
# .golangci.yml file at the top level of your repo. | |
script: | |
- golangci-lint run # run a bunch of code checkers/linters in parallel | |
- go test -v -race ./... # Run all the tests with the race detector enabled |
Poorly the config does not work anymore:
https://github.com/bykof/go-plantuml
https://travis-ci.com/bykof/go-plantuml
I've replaced building golangci-lint
from vendor/
with fetching the compiled binary from GitHub. This reduces the number of packages listed in go.mod
.
Yeah, this has been breaking for me. AFAICT the problem is that Travis doesn't support Go 1.13 (4 months old!). If this is true, then Travis is truly dying. I'll post an example CircleCI config soon and encourage people to migrate. Spoiler: It's much faster 🙂
Awesome, thank you :)
Here's my example config for CircleCI. It's a good starting point for most projects.
I recommend CircleCI over Travis. By building, linting, and testing using containers instead of VMs, CI completes much faster. My q project takes about 20s per CI run. Both Travis and GitHub Actions take a minute just to spin up the VM. Circle finishes before they even start.
Hi @y0ssar1an I need you help, I am middle of a travis CI integration where i want to add a stage condition or a job condition where it would allow only the build job to run if the pull request is merged.
something like this as shown below:
stages:
- name: PushBuild
if: (branch = master) AND (type = push)
When i tried with above got error as below
rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
/home/travis/.rvm/gems/ruby-2.5.3@global/gems/rake-12.3.2/exe/rake:27:in <top (required)>' /home/travis/.rvm/gems/ruby-2.5.3@global/bin/ruby_executable_hooks:24:in
eval'
/home/travis/.rvm/gems/ruby-2.5.3@global/bin/ruby_executable_hooks:24:in `
(See full trace by running task with --trace)
The command "rake" exited with 1.
Is this because of syntax issue with GO ?
@akash355 The error message is pointing to a missing Rakefile, so I don't think that has anything to do with Go. Are you using Ruby in your project? This .travis.yml
file is only for Go projects.
I would debug this by inserting ls
commands into your .travis.yml
at a point prior to the failure. It will show you what files are present on the Travis CI runner. Good luck!
Thank you for the suggestions, guys! I've updated the travis file. Let me know if there are any other improvements I can make.