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. For more options, visit https://groups.google.com/groups/opt_out.
