Based on publish-to-ftp and extending publish-to and basic-credentials this Jenkins plugin publishes artifacts in a post-build to dropbox folders without the need to run a sync client on your build server.

There are 3 options:

1. Install the plugin through the Jenkins plugin manager. (Version 1.0.5 is available at this time)
2. Install a beta
3. Compile your own
4. Create an own Dropbox app in the on https://developer.dropbox.com/
5. Clone the sources and update the Config.java with your personal client id and client secret.
6. Run the "mvn hpi:hpi" on the project source code
7. Install the generated publish-over-dropbox.hpi on the advanced section of the plugin manager of your Jenkins installation.

Version 1.2.0 of the Dropbox plugin is out. It is now possible to use the new Jenkins pipeline DSL to configure the Publish over Dropbox plugin.

More info on: Build pipelines

The versions of the plugin before 1.1 use the Dropbox V1 API. These are deprecated by Dropbox will stop working from June 28, 2017.

• Update your plugin to at least 1.1.2

The versions before 1.1 use a API token coupled to a business account. That account might not exist in the future, which can block all derived Tokens. Uploads will fail after that.

1. Update your plugin to at least 1.1.2
2. Generate a new Token. You can by retaking the first configuration step: Link an account. (as described below)

The highest level is connecting a Dropbox account to Jenkins. Dropbox account connections can be created in the *Jenkins > Credentials*.

The second level is to create a location for a previously linked account. Locations can be created in *Jenkins > Manage Jenkins > Configure System*.

The last level is to actual publish files to a Dropbox location. Publishing can be done as *Post-build Actions* in your build job configuration.

The last level is to actual publish files to a Dropbox location. Since version 1.2.0 publishing can be configured with Pipeline DSL in your build job configuration.

Using the Snippet Generator you can create code for the DSL publishing. A simple step only provides the required parameters: configName, sourceFiles and remoteDirectory,

All the options available in the classic mode are also available in the DSL syntax.

A description of all the parameters are:

Files to upload to the Dropbox location.

The string is a comma separated list of includes for an Ant fileset eg. '**/*.zip' (see patterns in the Ant manual). The base directory for this fileset is the workspace.

Select an Dropbox location from the list configured in the global configuration of this Jenkins. The configuration defines the account properties and base directory of the Dropbox location.

Destination folder.

This folder will be below the one in the global configuration. The folder will be created if does not exist.

Only create files on the server, do not create directories (except for the remote directory).

All files that have been selected to transfer must have unique filenames. Publishing will stop and fail as soon as a duplicate filename is found when using the flatten option.

Select this to include the timestamp in the remote directory.

The timestamp is the date of build. This setting turns the remote directory option into a java SimpleDateFormat. The SimpleDateFormat(SDF) uses letters to represent components of the date, like the month, year, or day of the week. The SimpleDateFormat page has more information about the date patterns. As the SDF reserves all of the letters [A-Z][a-z], any that you want to appear literally in the directory that is created will need to be quoted.

Select to delete all files and directories within the remote directory before transferring files.

Directories older then the max days will be deleted.

A date format directory format can lead to a long list of directories. Removing old directories in the remote root will allow you to prune that list.

Directory created more then this number of days ago are considered old for pruning of root.

First part of the file path that should not be created on the remote server.

Directory structures are created relative to the base directory, which is usually the workspace.You normally do not want the full path to these files to be created on the server. For example if Source files were target/deployment/images/**/ then you may want Remove prefix to be target/deployment This would create the images folder under the remote directory, and not target/deployment

If you use remove prefix, then ALL source file paths MUST start with the prefix.

Link to changelog here

This project builds upon the publish-over-plugin by Anthony Robinson

Also this project builds upon the credentials-plugin by CloudBees, Inc., Stephen Connolly

And much inspiration was found in the publish-over-ftp-plugin by Anthony Robinson

Uses a copy of the RuntimeTypeAdapterFactory by Google Inc. licensed under the Apache V2 License.

The MIT License (MIT)

Copyright (c) 2015 René de Groot and other contributors.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.