I have configured github repository for travis-ci, ref .travis.yml
It takes almost two minutes to build, travis is busy with the actions like this:
Is there a way to speed-up the process? I have read Migrating from legacy to container-based infrastructure but seems that simply "sudo: false" does not work. Can I do something else?
You can get rid of updating libc by moving to the trusty environment. The following will probably have least overhead:
sudo: false
dist: trusty
Related
first let me tell you I am a quite beginner with Circleci, so some of my questions might not make too much sense but bear with me.
Recently I published a project of mine in Github PoC Akka FSM, I heard from several friends good things about Circleci and I am trying to use for my project.
Circleci web page created a config.yml for me and it is looking good but I have a complication, my Project is a Gradle Project but it has a dependency to Eclipse .p2 Repositories, which Gradle can't resolve out of the box. So I have a small Maven Project that collects my dependencies from .p2 repository and convert those to a big fat dependency jar.
Now when I locally build, I build first maven project which would place the the dependency in local maven repository, so the Gradle can locate the Artifact from Maven repository.
Now for the reason you might guess this is not working in Github with Circleci's default config.yml, so my question would it be possible to combine a maven build and gradle build in Circleci. Or a define in a prestep for an extra Build.
Otherwise I will try to convert Maven project to Gradle project (I am not sure Gradle would be able to read .p2 repositories).
The following is the Maven Project.
Thx for answers
I solved my Problem and I like to explain here how, in case another complete beginners lands here.
First, if you are complete new to CircleCI please start reading this before anything else, life would be much easier.
CircleCI Concepts
Secondly, this link
CirceCI Sequential Jobs
explains perfectly how Sequential Jobs should work, at the beginning the wordings 'Steps' being under 'Job' and 'Workflow' confused me a lot, I was not sure I have to implement my Maven Step in Job or Workflow, but it seems it must be Workflow.
Third, I was not quite sure how to transfer the Artefacts of Maven Build to Gradle Build, it seems Cache mechanism is responsible for it. When first I read it, a cache in Build System didn't not made too much sense but I think (I am completely speculating) caches in CirceCI is like Java Maps, you put in Job a value with key, next job can pick the value for key (value being here the Artefacts?). So I in my Maven Job, I am saving my Cache with Key "v1-dependencies-{{ checksum "fsm-akka-eclipse-dependencies/pom.xml" }}" and in the next Job, I load it with same key (and additionally v1-dependencies-{{ checksum "build.gradle" }} while I have a feeling if the checksum of 'build-gradle' is not changed CircleCI optimize something) Someone with more experience may be clear that here
Fourth, I was not sure how to say CircleCI to install Maven or Gradle but it seems CircleCI doing it in a magic way. In my previous point, I mentioned the caches to transfer the Artefacts', but for Maven Job, I am telling to save the cache at '.m2' directory which normally Gradle will look for Maven Artefact, may be this is doing the trick or the Cache I can't tell.
If you like the see how my final config.yml looks, you can find it on the link.
I've got a lot of queued Travis-ci.org jobs showing 'Build created successfully" but nothing is happening. It looks like Travis has got itself into a look creating jobs for my last few commits and not processing any of them. How can I clear out these jobs?
OK so I really don't understand what a travis-ci.org 'request' is because the problem was a bad .travis.yml file and once I fixed that, the CI started again. But the 'requests' are still there :-(.
The 'solution' was to install the travis command-line tool which includes 'travis lint' and allowed me to lint my .travis.yml file until it was at least happy. The downside to this is that, on Windows at least, installing the travis tool took a lot of time and a lot of disk space as it instaled Ruby, MinGW and lots of other stuff that I will probably never use again!
But until travis-ci.org/com creates an on-line linter (how hard can it be?), that's what we're stuck with. OTOH, the first step of the travis-ci.org/com build could be to lint the file and complain if it fails - just a suggestion :-).
Whenever I push a new commit, Travis CI fails my build with this message at the top of every log:
WARNING: We were unable to find a .travis.yml file. This may not be
what you want. Build will be run with default settings.
Using worker:
worker-linux-docker-71483f98.prod.travis-ci.org:travis-linux-6
Could not find .travis.yml, using standard configuration.
However, I definitely have a .travis.yaml file in the root of my repository. Here are its contents:
$ cat .travis.yaml
language:
node_js
node_js:
stable
script:
node_modules/grunt-cli/bin/grunt
Some people seem to have encountered similar issues because they renamed their repositories, but I have never changed the name of this repository. Others say it just fixed itself after a couple hours, but it has been 5 days for me and nothing has changed.
Nothing in the Travis CI documentation seems to indicate that I need to do anything more than sync my repos, active the repo I want CI for, and include a .travis.yaml file in the repo. Am I missing something?
You are using the wrong extension for your YAML file.
It needs to be .travis.yml not .travis.yaml.
I just cannot hook up the automatic update of coveralls.io to my Travis-CI build. All works fine if I execute the scripts on my machines. Here is the last message from the build log:
Submitting coverage to coveralls.io...
Coverage submitted!
Couldn't find a repository matching this job.
'url'
The command "python travis-ci/run.py" exited with 0.
Any hints or suggestions would be highly appreciated.
Best, Philipp
Make sure the TRAVIS, TRAVIS_JOB_ID and TRAVIS_BRANCH environment variables are defined when calling coveralls.
If you're using Tox for example, an extra step is needed as described in the coveralls-python readme.
This question is older, but the current problems show the same error. (And Google finds this too :-))
There were issues opened about it in node-coveralls and coveralls-public (and one more) repositories. It appeared, that Coveralls got accidentally blocked by Travis.
Although the problem was supposed to be fixed, as the comments on the second issue suggest, it occurred again. I myself could upload a new report neither from my machine, nor from Travis. I switched from Coveralls to Codecov.
I've stuck with this issue while configuring Jenkins for Nightly build. Please note that the repository project "project1" is large and is about 900MB. Please let me know how should I go around this problem.
Started by user anonymous
Building in workspace C:\Users\user1\.jenkins\jobs\Nightly Build\workspace
Fetching changes from the remote Git repository
Fetching upstream changes from git#github.com:MyOrg/projectgroup/project1
ERROR: Timeout after 10 minutes
FATAL: Failed to fetch from git#github.com:MyOrg/projectgroup/project1
hudson.plugins.git.GitException: Failed to fetch from git#github.com:MyOrg/projectgroup/project1
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:612)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:836)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:861)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1412)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:557)
at hudson.model.Run.execute(Run.java:1679)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:509)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:230)
Caused by: hudson.plugins.git.GitException: Command "fetch -t git#github.com:MyOrg/projectgroup/project1 +refs/heads/*:refs/remotes/origin/*" returned status code -1:
stdout:
stderr:
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:981)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:920)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.fetch(CliGitAPIImpl.java:187)
at hudson.plugins.git.GitAPI.fetch(GitAPI.java:229)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:610)
... 10 more
I was about to use Workaround #2 but it seems as of git plugin 2.0.3 this can now be configured in the UI, although it is a bit hidden away and is per project.
Go to the configure screen for a project, Source Code Management section, Git, Additional Behaviors, Add, Advanced clone behaviors, Timeout (in minutes) for clone and fetch operation.
I would use workaround #2 as suggested by DevHopeful_2012 if you want a global setting.
It looks like this is a known issue. See JENKINS-20445, JENKINS-20387, and several other issues, which seem to be popping up.
According to these bug reports, this is only happening in the newer version of the Git plugin, so you could downgrade, or try some workarounds:
Workaround #1 - create a local bare reference clone to reduce the time, as stated here.
If you have only 30 kb/second throughput from Jenkins to your git repository, you should probably consider cloning a bare copy of the
repository to central location on the Jenkins server, then perform the
clone with the "Advanced clone behaviour" to use a reference
repository. That will significantly reduce the amount of data
transferred from the git server to Jenkins.
On my Debian Jenkins machine, I do that with:
$ sudo mkdir -p /var/cache/git/mwaite
$ sudo chown mwaite.mwaite /var/cache/git/mwaite
$ cd /var/cache/git/mwaite
$ git clone --bare https://github.com/jenkinsci/jenkins.git
After that bare clone is available on the Jenkins machine, add that
advanced behavior to the job and it should perform much better.
Workaround #2 - increase the timeout to allow for the long initial clone process to complete, using the Git.timeOut property:
java -Dorg.jenkinsci.plugins.gitclient.Git.timeOut=60 -jar jenkins.war
This SO question is a good example of how to set properties for the Jenkins service. Also, note that this value is in minutes and not seconds. This workaround is courtesy of David.
The latter workaround worked for me. Although, I must admit that I'd prefer to use the reference repo, but I don't believe that it works with a multiconfiguration job, such as mine. And, be forewarned that it was surprisingly painful to set a property for every slave node and then internally document that we have to set this on all nodes, using large Git repos, going forward.
WINDOWS ONLY
There is a possibility that your ssh connection is not configured properly. If the ssh connection to your git repository is not estabilished, Jenkins build may appear as if it hung and eventually timeout.
By default, the Jenkins installer sets up Jenkins to run as a service,
which runs as the “Local System account”, NOT your user account. Since
the “Local System account” does not have SSH keys or known_hosts set
up, “git clone” will fail.
You can just copy C:\Program Files (x86)\Git\.ssh to
C:\Windows\SysWOW64\config\systemprofile\.ssh (the “Local System
account” home)
Also,
IMPORTANT: make sure your ssh keys do NOT have a password! Jenkins
will appear to hang when cloning the repository, but really it’s ssh
blocking in the background waiting for you to input your password.
Detailed steps in http://computercamp-cdwilson-us.tumblr.com/post/48589650930/jenkins-git-clone-via-ssh-on-windows-7-x64
I just found the solution for jenkins timout #10 min errors. This error was coming because of low Internet connection or may be the size of you project in github is large, so jenkins not able load that project from git server.For resolve the problem we have to edit "Additional Behaviours" in Git in jenkins project configuration and increase "Timeout (in minutes) for clone and fetch operations" to "60" or "120" minutes. So now whenever jenkins clone the git project from git server, its enough time to load/clone a project from git server.
Workaround #2 worked for me, I had to change jenkins.xml file.
On Windows:
Go to C:\Program Files (x86)\Jenkins
open jenkins.xml file
add -Dorg.jenkinsci.plugins.gitclient.Git.timeOut=60 inside <arguments> tag
This is how my configuration looks like
Before:
<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=8080 --webroot="%BASE%\war"</arguments>
After:
<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Dorg.jenkinsci.plugins.gitclient.Git.timeOut=60 -jar "%BASE%\jenkins.war" --httpPort=8080 --webroot="%BASE%\war"</arguments>
In Ubuntu 14.04 lts
Goto /etc/default/jenkins edit with vi or gedit
update java orgs like below
Before update, it will be like
JAVA_ARGS="-Djava.awt.headless=true"
Update like below
JAVA_ARGS="-Djava.awt.headless=true -Dorg.jenkinsci.plugins.gitclient.Git.timeOut=30"
and restart jenkins like
sudo /etc/init.d/jenkins start
On CentOS/RedHat 7.4 Linux with Jenkins-2.138
Edit /etc/sysconfig/jenkins, modify the JENKINS_ARGS (last line) with the timeout setting mentioned by others in their answers:
# Pass arbitrary arguments to Jenkins.
# Full option list: java -jar jenkins.war --help
#
JENKINS_ARGS="-Dorg.jenkinsci.plugins.gitclient.Git.timeOut=25"