Prefetch mozmill-automation and mozmill-tests repositories #60
Conversation
| <keepDependencies>false</keepDependencies> | ||
| <properties> | ||
| <hudson.queueSorter.PrioritySorterJobProperty> | ||
| <priority>1099</priority> |
There was a problem hiding this comment.
Would you mind also adding the priority to the get_mozmill-environment job?
|
In general the patch looks good. We should only figure out and fix the remaining small issue.
There is no staging environment available yet. But feel free to test it on Linux and Windows too locally. There is really not much to do to get it running. Just add two of those slaves. I would appreciate a full testing cycle before I want to land it on masterblaster.
That's one more thing we have to check than to be sure it works. Just fix a nit or the readme.
If we would make use of the plugin would the Mercurial instance has to be installed globally on this box, or could we reference the binary? |
You need to reference the binary from the global configuration, which wouldn't work with what we've got at the moment. I will investigate with including mercurial in jenkins-env. |
…ozmill-automation repositories.
|
Updated to use the Mercurial plugin for fetching the repositories. Also made the jobs cross platform. Changed the tools job to not be platform specific. Feedback welcome whilst I test this latest version. |
|
Sorry, but I accidentally commented on your latest commit. So please check your repository. I kinda like where we are heading to. Can't await to see it landed. |
ghost
assigned
|
Updated and ready for review again! :) |
| @@ -1,2 +1,3 @@ | |||
| mercurial | |||
| python-jenkins | |||
| MozillaPulse | |||
There was a problem hiding this comment.
Hm. I haven't thought about that yet but we should stick to specific versions for all three packages. You an file a separate bug if you want.
There was a problem hiding this comment.
Good point. Raised as issue #66
|
Updated to fix branches issue. |
|
As discussed on IRC all jobs fail which depend on the downloaded repositories due to: 2 archives were successfully processed. This failure appears after unzipping the archives. And the warning I see is: Archive: mozmill-tests.zip |
|
As discussed, I've been going round in circles. So XShell forces running from the workspace directory (so mozmill-automation for example). This means I can't create an zip file that includes the 'mozmill-automation' folder. So when the zips are being extracted, the are going into root and clashing. The proposal is to create a couple of 'archive' scripts in tools that will can be used cross platform. |
|
|
|
This just gets more fun! So I'm now using the Clone Workspace Plugin, which takes care of zipping up the workspace of a successful build and unzipping it into the necessary jobs. I've even been able to clean up the way we handle the Mozmill environments, so that the only job that requires tools is the one that gets the zipped environment. The problem I've now hit is JENKINS-13165, which was actually introduced in the version of Jenkins we're using. It's been fixed in the latest version of Jenkins (1.463) but the plugin also needs to be updated. A pull request is open, and hopefully a new version will be released soon. In the meantime I will continue with the latest version of Jenkins that does not present this issue... |
|
I have success at last! I have been able to successfully run a testrun on Mac, Windows, and Linux using Jenkins 1.455 and the Clone Workspace plugin. I will put together a new commit this evening and comment here when the pull is updated and ready for another review. I will also submit a new issue to upgrade to the latest Jenkins and the as yet unreleased latest version of the Clone Workspace plugin. |
|
Dave Hunt reply@reply.github.com schrieb:
Would you mind also updating xshell which hasn't been done yet.Henrik Skupin |
|
Updated to use the Clone Workspace plugin. Ready for review again. |
| <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding> | ||
| <triggers class="vector"> | ||
| <hudson.triggers.SCMTrigger> | ||
| <spec>*/15 * * * *</spec> |
There was a problem hiding this comment.
For testing I have changed it to '* * * * *'. There are no new jobs added to the queue/history. Does it mean that the job only gets executed and listed in the history if a change happened to the repository?
There was a problem hiding this comment.
Yeah, that was the case. Good to know. It works fine.
|
Otherwise it really really like it! |
|
Landed as: |
This change adds two jobs that clone the mozmill-automation and mozmill-tests repositories and make them available as artefacts for other jobs. A URLTrigger plugin is included, and the jobs are set to check the RSS feed for the repositories and build whenever a change is noticed (polling every 15 minutes).
I have tested the builds on Mac, however I would appreciate some additional testing. Do we have a staging environment at all? In particular, I'm interested to see if the unzip command on Windows will unzip all zip files or if they need to be individually named.
Also, during my testing nothing has been pushed to either repository, so I have yet to see the URLTrigger working, but I have successfully used this plugin before.
Unfortunately I don't believe we can use a Mercurial hook because the repository server would need to be able to communicate with Jenkins, which is behind the VPN. Also, I believe that polling of the repository is only possible if a job is set up with an SCM. Doing this for Mercurial would mean installing the Mercurial plugin for Jenkins, and add a prerequisite of Mercurial installed. The way I have set this up will use the version in the Mozmill environment.