A way to get rid of useless local workspace?

[Gilles Kacki]

From my jenkins server, builds are triggered with Ant remotely on building machines. 

I inserted a "Build Trigger" with "Poll SCM" to listen to changes in my SVN repository,

But as all my builds are run remotely i do not need a checkout of my repo locally on my jenkins server.

How can i avoid this useless & space-consuming workspace? Any option?

[Daniel Beck]

If there's a workspace for these jobs on Jenkins master, but they're running on slaves nodes due to a label expression in the job configuration, you should be able to just delete the workspace on the Jenkins master. It's probably left over from when the job was still running on the master.

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

[kgiloo]

probably my description lacked precision:
I should have titled "A way to get rid of useless checkout of repository into my local workspace".

I do not use any special slave configuration to trigger my builds on slaves, it is all driven by Ant.
In other words, checkout of repository is also performed by Ant on slave.

I need the "poll SCM" to kick off the build process, for nothing else, i.e checkout of repository in workspace has no sense on my master.

[Maciej Jaros]

kgiloo (2014-01-15 09:42):

You don't have to poll SCM. You can triggger builds from the repository using e.g. post-commit hooks in SVN. Just enable remote builds.

Regards,
Nux

[Maciej Jaros]

kgiloo (2014-01-15 09:42):

You don't have poll SCM. You can triggger builds from the repository using e.g. post-commit hooks in SVN. Just enable remote builds.

Regards,
Nux

[Les Mikesell]

Why do it that way? Why not include the ant script in the checkout
and let jenkins do it in the right place for you?

--
Les Mikesell
lesmi...@gmail.com

[kgiloo]

AFAIK if you configure the post-commit hook together with jenkins,
you must activate "poll SCM" anyway, else it won't start the build.
I followed instructions here:
https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

What i want to avoid is the checkout/update of repo into my workspace on new commit since it is overkill on my jenkins master...

[kgiloo]

Sorry, i did not get your point... What do you mean exactly?

[Les Mikesell]

My builds are all done on slaves and even though the master controls
the SCM polling, it does not check out any source locally on the
master. However, with usual setup, the slave checks out a copy of
the target the job is configure to poll before executing anything in
the job. So I don't understand how you avoid that - or why you want
to avoid it and make your own ant script do the slave checkout.
And I think whatever it is you are doing is making the master do the
checkout instead of the slave.

[Daniel Beck]

On 16.01.2014, at 15:16, kgiloo <gilles...@gmail.com> wrote:

> AFAIK if you configure the post-commit hook together with jenkins,
> you must activate "poll SCM" anyway, else it won't start the build.

Put the code to determine which change in the repository needs to trigger which job into the post-commit hook, and enable 'Trigger builds remotely' for those jobs.

If you have enabled Jenkins security, either pass username and password (or API token), or use https://wiki.jenkins-ci.org/display/JENKINS/Build+Token+Root+Plugin

Then you can disable SCM polling and remove any SCM configuration from the Jenkins jobs.

[kgiloo]

Thank you so much for your explanation!
It seems now easy to define a new slave, trigger svn update on it with SCM poll, and execute the Ant script from that location.
Don't need even my Ant remote task anymore with jenkins slave agent...

[Les Mikesell]

It is pretty much the point of the slave agent and the way jenkins
works to do all of the remote work for you. I wasn't sure if you did
not understand that or if you had some special requirement to run your
own remote ant script. If you want some things to be copied back to
the master, add a post-build action to 'archive the artifacts' and
specify the files you want.

--
Les Mikesell
lesmi...@gmail.com

[gorill...@gmail.com]

It seems pretty inflexible. Why not just separate polling from checkout? One step to poll repositories, and one step to checkout.

[Les Mikesell]

On Wed, Mar 26, 2014 at 12:42 PM, <gorill...@gmail.com> wrote:
> It seems pretty inflexible. Why not just separate polling from checkout? One
> step to poll repositories, and one step to checkout.

It seems odd to care if the contents of a repository changed if you
aren't going to use them in the job that is triggered. Do you have
some unusual requirement?

--
Les Mikesell
lesmi...@gmail.com

[Peter Savage]

"It seems odd to care if the contents of a repository changed if you
aren't going to use them in the job that is triggered."

That is so loaded with inherent assumptions I don't even know how to touch it.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/-WqmXrEdAEg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Les Mikesell]

On Wed, Mar 26, 2014 at 1:31 PM, Peter Savage <gorill...@gmail.com> wrote:
> "It seems odd to care if the contents of a repository changed if you
> aren't going to use them in the job that is triggered."
>
> That is so loaded with inherent assumptions I don't even know how to touch
> it.

Yes, and it matches the assumptions built into jenkins. That is, it
works as designed for a lot of people. I think it is a reasonable
assumption that if you trigger a job on a repository change that you
are planning to use the contents.

--
Les Mikesell
lesmi...@gmail.com

[Chris Marks]

I think a better answer to this is that this is not a typical use case for people or teams using Jenkins.  Although I can see some value to something like this, it may not have enough support in general to change the behavior of Jenkins.  I had a situation in the past for a similar need.  At that time, the code base was sufficiently small that the checkout was fast enough for my needs.  It sounds like another tool or process may suit your needs better if this is not the case.

Hope this helps, 

topher

Thanks,
Chris

tophe...@gmail.com

--
   Les Mikesell
     lesmi...@gmail.com

--

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-use...@googlegroups.com.

[Peter Savage]

Thats fine, but insisting that I dump the contents of that repository onto disk in a specific fashion may or may not help me use the contents. You keep insisting that a checkout into a directory controlled by the Jenkins server is a necessary part of the way one must use the contents. I disagree.

--
   Les Mikesell
     lesmi...@gmail.com

[Les Mikesell]

On Wed, Mar 26, 2014 at 4:48 PM, Peter Savage <gorill...@gmail.com> wrote:
> Thats fine, but insisting that I dump the contents of that repository onto
> disk in a specific fashion may or may not help me use the contents. You keep
> insisting that a checkout into a directory controlled by the Jenkins server
> is a necessary part of the way one must use the contents. I disagree.

No, it doesn't have to be on the jenkins server. If you want it
somewhere else, run a jenkins slave there and configure the workspace
where you want it to be. That's just the way jenkins works. It may
not be the best thing for whatever it is that you are trying to do.
There are other ways to check remote revisions and get the contents as
unrelated events.

--
Les Mikesell
lesmi...@gmail.com