There is also the github pull request builder which will build the merge of your pull request every time you commit to the branch in the pull request. This way you can get the results of the tests, see it failed, fix it, push your change back to your branch, and the tests will run again. You can basically get CI on your branch if you open a pull request immediately. You could even have it deploy the built artifact for the tester to test before anything is even merged to the main line of development. By the way I am doing a lightning talk about this very thing at JUC Palo Alto.
Will On 08/05/13 07:27, Tom Moore wrote: Alternatively, if you have a requirement for code passing test/compiling, etc before checkin and you can't or don't want to use private repositories/branches, you can look at developing a variation of your build process that uses the filesystem SCM plugin. Run the build/tests against the files in the filesystem, and if they pass then they are permitted for checkin.... you can even run a post-build script if the build is successful to perform the check-in for you. Of course this method can require a lot of slave nodes defined to support all your developers so that it can find their local filesystem source, plus depending on the level of user specific variables in your build you might have fun with lots of parameters. On Monday, August 5, 2013 2:28:31 AM UTC-4, Avihay Eyal wrote: Thanks for your ideas. I think an on-demand script would fit my organization, but I'll take into account the way that GIT script works. On Monday, August 5, 2013 4:20:05 AM UTC+3, Mark Waite wrote: ________________________________ From: Avihay Eyal <aviha...@gmail.com> To: jenkins...@googlegroups.com Cc: dirk.he...@recommind.com Sent: Sunday, August 4, 2013 12:37 PM Subject: Re: CI usability - isn't there a problem that tests are executed only after a developer pushed his changed to the repsitory? I'm using Mercurial, which is a distrusted source control. So you're suggesting using a script, activated via commits to the developer local repository? Once the developer committed changes to it's repository, the script will build that changes with the latest code, run all the regression tests, unit test, etc...If the test pass fine, then the developer can choose if he wants to push his changes to the main repository? I don't think that is how the Git plugin does what it does. I believe the Git plugin monitors multiple repositories and branch names for changes. If a change is detected in one or more repositories, the plugin merges those changes into its local branch, and attempts to run the job steps you specify (compile, test, deploy, whatever). The Git plugin has an optional step at the end, "Git Publisher" which will push the results of that merge to the remote specified in the plugin. I think that allows a workflow where the only user allowed to push to the authoritative repository is the Jenkins user. Other users push to their own repositories which are monitored by the Jenkins job. If their submissions are successful, then the results of merging their proposed change are pushed by Jenkins to the authoritative repository as the Jenkins user. I've been experimenting with a variant of that workflow and it has worked OK for me. My variant has been that by convention I never push to certain branches. Those branches only receives commits from Jenkins, and only after Jenkins has run some series of checks successfully. It has worked well enough, though I suspect it won't work in a larger organization, since it is a convention for users not to push to the integration branch, not an enforced rule. I think you could do the same with Mercurial and a script, though I'm not a Mercurial user, so I can't be certain. Mark Waite -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com<mailto:jenkinsci-users+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
