Workflow Plugin - Performing a Release

[RM]

Hi,

I recently started toying with the workflow plugin to script a build release. When i try to run the script, the release fails because the release plugin complains of untracked files. I have the same set of plugins running and working fine in a tradiitional job set up.

My set up

---------------

Jenkins Version:1.596

Workflow Plugins : 1.2

OS : Linux 2.6

Build Tool:Apache Maven 3.x

SCM : Git

Release Plugin:JGitFlow (from Atlassian)

My script reads 

node {

   

git branch: 'develop', url:' ******** '

        sh 'mvn clean install'

        sh 'mvn --batch-mode  jgitflow:release-start  jgitflow:release-finish -Prelease'

   

}

When i run this script(which is extremely simple),the release fails reporting the presence of untracked files.To debug this, I added a few git status commands intermittently and i can see the following files

.6e6a43dd/jenkins-log.txt

.6e6a43dd/pid
.6e6a43dd/script.sh

When i run 'git status' on my workspace using the shell command line, it says i have no untracked changes.

Any pointers?

[Jesse Glick]

On Monday, February 23, 2015 at 10:43:54 AM UTC-5, RM wrote:

.6e6a43dd/jenkins-log.txt

.6e6a43dd/pid
.6e6a43dd/script.sh

When i run 'git status' on my workspace using the shell command line, it says i have no untracked changes.

This control subdirectory is created for the duration of every sh step. Perhaps there is some way to tell maven-release-plugin to ignore untracked files. If not, perhaps your .gitignore can list this pattern, though for that it would be helpful to have a predictable top-level directory name. (It used to be .jenkins/ but got changed to use a random ID to allow concurrent steps in one workspace. Probably .jenkins/636a43dd/ is what we want.) File an RFE in durable-task-plugin with label workflow if you think this would be helpful.

[Vincent Latombe]

As I understand it, this id is a hash of the workspace path already. IMO this is not something that should be exposed to the workspace (as the control files are something Jenkins-internal), Couldn't this be stored directly in a specific metadata folder outside of any workspace?

Vincent

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ed1031e1-0858-478d-aac9-cbd1527a2d26%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Vincent Latombe]

2015-02-26 19:10 GMT+01:00 Vincent Latombe <vincent...@gmail.com>:

As I understand it, this id is a hash of the workspace path already.

Actually some kind of uuid, after a second read ;)

[Jesse Glick]

On Thursday, February 26, 2015 at 1:11:23 PM UTC-5, Vincent Latombe wrote:

Couldn't this be stored directly in a specific metadata folder outside of any workspace?

Probably yes, so long as it is within the “slave root” folder, so you do not get cross-device issues etc. Please file this suggestion in durable-task-plugin. For example that would obviate the original trigger condition for JENKINS-26105.

[Vincent Latombe]

Filed https://issues.jenkins-ci.org/browse/JENKINS-27152

Vincent

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3a631a3f-42f9-444b-afe8-79b8e8531901%40googlegroups.com.

[RM]

Thank you for helping out.

Yes, i can ask the release plugin to ignore untracked files but i was just wondering what was going on. 

It does make sense to generate these control files outside the workspace