[Mono-dev] Switch off the Jenkins ARM builds on PRs for now

[Slide]

You can turn on concurrent building in the project settings on Jenkins.
There are some caveats, see below.

Execute concurrent builds if necessary:

If this option is checked, Jenkins will schedule and execute multiple
builds concurrently (provided that you have sufficient executors and
incoming build requests.) This is useful on builds and test jobs that take
a long time, as each build will only contain a smaller number of changes,
and the total turn-around time decreases due to the shorter time a build
request spends waiting for the previous build to complete. It is also very
useful with parameterized builds, whose individual executions are
independent from each other. For other kinds of jobs, allowing concurrent
executions of multiple builds may be problematic, for example if it assumes
a monopoly on a certain resource, like database, or for jobs where you use
Jenkins as a cron replacement. If you use a custom workspace and enable
this option, all your builds will run on the same workspace, thus unless a
care is taken by your side, it'll likely to collide with each other.
Otherwise, even when they are run on the same node, Jenkins will use
different workspaces to keep them isolated. When Jenkins creates different
workspaces for isolation, Jenkins appends "@num" to the workspace directory
name, e.g. "@2". The separator "@" can be configured by setting the system
property "hudson.slaves.WorkspaceList" to the desired separator string on
the Jenkins command line. E.g. "-Dhudson.slaves.WorkspaceList=-" will use a
dash as separator.

On Thu Feb 19 2015 at 2:19:09 PM Alexander Köplinger <
alex.koeplinger at outlook.com> wrote:

> The Jenkins ARM builds cause quite some delays in PR building as they are
> slower than an amd64/i386 build and Jenkins can only start the next build
> when the previous one finished on all architectures.
>
> What's your opinion on switching off the ARM builds for pull requests for
> now until more workers can be brought online to better handle PR spikes?
>
> -- Alex
>
>
>  _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20150219/83e62c45/attachment.html>