jenkinsci / file-operations-plugin

File Operations as Build Step in Jenkins
https://plugins.jenkins.io/file-operations
33 stars 31 forks source link

Allow copy and delete of ant default exclude files #105

Closed RandomInEqualities closed 4 months ago

RandomInEqualities commented 4 months ago

Hi,

I recently had to setup at build machine and noticed that it is not possible to copy or delete .gitignore files. We are using this plugin for file operations, so it is a bit annoying and I thought I would try a pull request.

Currently, it is not possible to copy or delete files with the following names when using FileCopyOperation and FileDeleteOperation:

CVS .cvsignore SCCS vssver.scc .svn .DS_Store .git .gitattributes .gitignore .gitmodules .hg .hgignore .hgsub .hgsubstate .hgtags .bzr .bzrignore

Since the glob Ant pattern that FilePath::list and FilePath::copyRecursiveTo uses cannot pick up the files. This change changes to not use the default exclude list, so e.g. it is possible to copy and delete .gitignore files.

The Ant default exclude files are listed here: https://ant.apache.org/manual/dirtasks.html#defaultexcludes

Testing done

I have added two automated tests that fail before this change, and pass after the change.

Submitter checklist

jonesbusy commented 4 months ago

Hi,

Thanks for your PR.

From what I saw it's a breaking change for users.

Could we add an optional option to those steps to not use default exclude if needed ?

Thanks.

RandomInEqualities commented 4 months ago

Hi,

Year sure. I am not too familiar with Jenkins plugins. Would adding overloaded functions to FileOperationsJobDslContext work? Something like this:

image

? In the same way would you prefer to have the input to the FileCreateOperation, FileCopyOperation and FileTransformOperation as constructor parameters or setter functions?

RandomInEqualities commented 4 months ago

Ideally I think a plugin wide boolean check would make sense, if that is possible? So it can be turned on an off for the whole plugin and not per function.

jonesbusy commented 4 months ago

Hi,

I think the best is to use https://javadoc.jenkins.io/component/stapler/org/kohsuke/stapler/DataBoundSetter.html

Generally mandatory argument are passed on the constructor via https://javadoc.jenkins.io/component/stapler/org/kohsuke/stapler/DataBoundConstructor.html and optional parameter via DataBoundSetter

RandomInEqualities commented 4 months ago

I have pushed a change that tries to use the DataBoundSetter, while also adding a test for FileTransformOperation. I have not tried to start a jenkins server and test it out. I have only run this project locally and run the tests, so I am not 100% sure if everything is ok with these changes.

jonesbusy commented 4 months ago

The code looks good to me. I will try to perform some interactive tests in the next few days. Thanks

jonesbusy commented 4 months ago

I think we need to be careful when adding new field

https://www.jenkins.io/doc/developer/persistence/backward-compatibility/#add-a-new-field

The default value must be true if not existent when the objects is resurected from storage (a job with legacy format loaded).

I think we can achieve it by

...
private Boolean useDefaultExcludes;
...

protected Object readResolve() {
  if (useDefaultExcludes== null) {
       useDefaultExcludes = true
  }
  return this;
}

The default value on the constructor can be kept when the object is created from code and not from storage.

I cannot confirm 100% of this, but I think it's the way to go

RandomInEqualities commented 4 months ago

Year you were right, I added tests for the XStream serialization and indeed the readResolve was needed. It should be fixed now!

jonesbusy commented 4 months ago

Thanks for your PR, will be released in some minutes