Pour chaque job, Jenkins alloue un "répertoire de travail" unique. Il s'agit du répertoire où le code est placé en provenance de l'outil de gestion de configuration et où les builds ont lieu. En règle générale, vous devriez laisser Jenkins allouer et nettoyer les répertoires de travail, mais dans certaines circonstances, cela peut poser problème. Cette option vous permet de spécifier le répertoire de travail manuellement.

Un exemple d'une telle situation est quand les chemins sont codés en dur et que le code a besoin d'être construit à partir d'un emplacement spécifique. Il est certain qu'une telle configuration de build est déconseillée, mais cette option vous permet néanmoins d'avencer dans ces circonstances.

Un autre cas où cette option est utile est lorsque vous utilisez le type de projet 'free-style', non pour construire un projet logiciel mais pour exécuter certaines tâches en batch, par exemple à la place d'un cron. Dans ce cas, utilisez cette option pour allouer un répertoire spécifique au répertoire de travail du batch, afin que les utilisateurs puissent accéder aux fichiers directement à travers l'interface web de Jenkins. Il sera également possible de lancer les commandes plus facilement.

Si vous êtes dans un environnement distribué, à moins d'associer un job à un noeud (une machine) spécifique, Jenkins sera toujours capable de déporter des jobs sur différentes machines esclaves, même si cette option est utilisée. Parfois, cela est souhaitable; parfois, non.
Par ailleurs, il est possible d'associer plusieurs projets à un même répertoire de travail; assurez-vous dans ce cas que des exécutions concurrentes de ces jobs n'interfèrent pas de façon adverse les unes avec les autres.