Hi jtnguyen23,

Thanks for the feedback! Just so you know, you don't actually have to setup a job parameter, the plugin will just inject the `pmt_attachmentsDirectory` variable straight into the job for you.

Regarding the download directory, I was thinking we'd need to generate a new directory each time, to make sure we're not overwriting the previously downloaded attachments (in case the same filename's clash). I like your idea, of being able to specify a parent folder to download them into though.

How would you expect/like it to behave?

1. be able to turn on/off downloading attachments in the plugin configuration?
2. be able to specify a target directory in the plugin configuration OR just use the "java.io.tmpdir" location?
3. do you want the attachments to download into the configured directory (overwriting files with the same name) OR should it create subfolders using a date timestamp (e.g. `parentFolder/yyyyMMdd-HHmmssSSS/`)?
4. anything else???

Just ask if any of this doesn't make sense. If you have any other options/ideas, would love to hear them!

Just fyi, the current behaviour is: using the "java.io.tmpdir" location, and then using `System.currentTimeMillis()` for the folder name (details here).

Let me know what you'd like and I'll make the changes, and then upload a new plugin for you to test! The existing plugin wouldn't cause the issue you're describing, but it'd be a good idea to have only one version installed at a time (I don't know what happens if you have multiple!??).

Kind regards,
Nick

1. be able to turn on/off downloading attachments in the plugin configuration?
   Yes, it would be nice to be able to turn it off in cases when all you are looking for are some key words in the subject line or email body to trigger the build. It there's an attachment that you don't care about, you don't want to a pile of useless attachments building up in a folder somewhere on your filesystem.
2. be able to specify a target directory in the plugin configuration OR just use the "java.io.tmpdir" location?
   Yes, would love to see the ability to specify a target directory as a job configuration property. Also would be nice to allow the user to specify the path on a job by job basis if possible. There could be multiple jobs using this plugin concurrently, each receiving an attachment with potentially the same name. If they all went into the same folder, you could imagine how confusing it would get, even with the uniquely timestamped folder names.
   
   And to be able to do it through the Jenkins web interface instead of having to open up an .ini or .properties file to change java.io.tmpdir would be great.
3. do you want the attachments to download into the configured directory (overwriting files with the same name) OR should it create subfolders using a date timestamp (e.g. `parentFolder/yyyyMMdd-HHmmssSSS/`)?
   So I'm using Perl scripts to process the attachment. In my particular case, I would like to be able to specify a static directory name in which my Perl script will know exactly where to find the attachment. I understand your approach to name the folders with the timestamp to avoid overwriting, but it introduces an element of unpredictability for me – I would have to loop through a number of folder to find the file that I'm looking for, assuming we have multiple different jobs running concurrently using this plugin and depositing their misc attachments into the same temp dir. I don't know which timestamp-named folder to look into that has my attachment. It would be nice if you had a user-defined property pmt_overwriteAttachment, which if set to 'yes', would overwrite the attachment in the specified folder. If set to 'no', maybe you could do something like what you're doing now, but name the folder by adding the timestamp to the end of the filename, i.e. helloworld.pdf-143559433. It would help to make things a little bit more predictable when scripting and not have to do a linear iteration through all of the plainly timestamp-named folders.
   
   But to make things simple for you, I think most users would be fine to have the files overwritten each time something new comes in with the same name. Make them pay for the premium version of the plugin if they want something more elaborate.

Excellent! Currently the plugin is already configured on a job-by-job basis - so that answers that. Also, the 'pmt_attachmentsDirectory' will only ever point to the "latest" directory, so you shouldn't need to go searching for your files (as long as you know the filename -> on that note, did you want the filenames as parameters? e.g. pmt_attachment_1=myfile.jpg or pmt_attachment_2=/absolute/path/to/anotherfile.xls).

Not sure if it's possible, but this is what I'm planning on adding:

Let me know what you think (re: wording/etc). I'll start on the changes tonight (+5 hours).

(Tracking work in github -> https://github.com/jenkinsci/poll-mailbox-trigger-plugin/issues/3 )

Didn't get it finished tonight, will try and have an update for you tomorrow.

Yeah, that screen shot looks awesome. You rock! Looking forward to the changes.

After reading and rereading your question about adding pmt_attachment, I have a better sense of what the pmt_* variables are now. And I understand now what you meant by "the plugin will just inject the `pmt_attachmentsDirectory` variable straight into the job for you". Sorry, I'm a little new to configuring jobs in Jenkins. When I added my own pmt_attachmentDirectory property into the Advanced Email Properties box, it overwrote the exact information that I was trying to get at – the timestamp-named directory in which the attachments were downloaded into. I thought the pmt_* variables were user defined input variables into your plugin code. They are actually output variables from your plugin code and are made available as input to user-defined scripts, i.e. perl testme.pl %pmt_attachmentDirectory%.

In any case, the changes that you are currently making are worthwhile and will make the plugin more robust. On the question of whether or not to add the pmt_attachment or not, I wouldn't bother. I would leave that up to the user to extract that information using a script. It's an easy enough algorithm to loop through the contents of a directory using a half decent scripting language. Looping through an undefined length of pmt_attachment_n variables requires a bit more involved algorithm.

Thanks a million for being generous enough to share your work! Fantastic plugin!

Hi jtnguyen23,

I had lots of trouble with the radio buttons, so ended up going with the select options - also, haven't got the "custom" directory option, it's just "Ignore" or "Download to timestamped directory" - too hard basket (for now).

Screenshot: https://github.com/jenkinsci/poll-mailbox-trigger-plugin#screenshots
Latest Download: https://bintray.com/artifact/download/nickgrealy/Jenkins_Plugin_Snapshots/poll-mailbox-trigger-plugin.hpi

If you could please give it a go, and provide me with any feedback, that'd be excellent!

Kind regards,
Nick

Hi,

Thanks a lot for this feature, i was looking for this.
Actually i was looking for "custom" directory option, it would be great if the same is incorporated/enhanced.
Any plan for that?

Till then i am using the below command in build step
move "%pmt_attachmentsDirectory%\<file_name>" "<target_directory>"
And this works.

Kind Regards

Arghya

Closing - issue is tracked in github (and has since been closed) - https://github.com/jenkinsci/poll-mailbox-trigger-plugin/issues/4