You can use the Bamboo SCP task to upload files from Bamboo directly to a remote server as part of a Bamboo job. The SCP task is able to copy multiple files and preserves the directory structure for the copied files.

See  Configuring a deployment task for an overview of Bamboo deployment tasks.

To configure an SCP task:

  1. Navigate to the Tasks configuration tab for the job (this will be the default job if creating a new plan).
  2. Click the name of an existing SCP task, or click Add Task and then SCP Task to create a new task.
  3. Complete the following settings:
     

    Task Description Helps you identify the purpose of the task.
    Disable this taskCheck, or clear, to selectively run this task.
    HostThe hostname or IP address of the remote server to which the files will be copied.
    Verify remote host fingerprint on connectEnter the host fingerprint to be verified. See below for more details.
    PortThe port number of the remote host that is used for the SSH connection. The default value is 22.
    UsernameThe username to use to connect to the remote host.
    Authentication TypePassword – the password associated with Username.
    Key without passphrase – browse to the SSH private key with which to authenticate with the remote host.
    Key with passphrase – browse to the SSH private key, and supply the passphrase, to use to authenticate with the remote host.
    Local PathThe local path (relative to the Bamboo working directory) to the files you want to copy. Use commas to separate files and directories. You can also use Ant-style pattern matching to include multiple files, such as **/target/*.jar.
    Remote PathThe path to the destination directory on the remote server.
  4. Click Save.

 

Host fingerprint

You can determine the fingerprint for a host by running:

ssh-keygen -l -F <HOSTNAME>

The fingerprint is the part of the response shown in the screenshot below:

  • No labels

21 Comments

  1. user-2e061

    This does not appear to work when selecting key without passphrase  (same with ssh task).

    A workaround appears to be:  set with bogus passphrase, save, change to without passphrase, save

    1. James Dumay

      Hmm sounds like a bug Ryan – I've raised a bug report for you and ill get it on schedule for 4.3.1.

      BAM-12369 - Getting issue details... STATUS

  2. bsarkar

    the "Local Path" is it relative or absolute ??

    1. James Dumay

      relative to the working directory (this is usually where your build checks out).

      1. bsarkar

        thanks

      2. david.s.mittman

        Oh, that information (Local Pat must be relative) is key to the success of the task, yet the task does not fail and does not emit a warning if you specify an absolute path or a path that points outside of the working directory.

        1. Greg Kopff

          This key piece of information really needs to be more prominently displayed.

  3. Clinton Volzke

    I'm trying to scp copy with ssh specifying a username and password (no keyfile yet, starting simple).

    I specified a relative path for 'local path', and an absolute path for the 'remote path'.

    What should I be doing next to resolve the problem? I also can't see any log file entries relating to scp.

    I'm running bamboo 4.3.3 build 3403

    Thanks in advance.

    1. James Dumay

      Hey Clinton - very long time mate!

      Is the local path relative to the working directory of your build? For example, something your build has produced or you have checked into version control?

  4. Clinton Volzke

    Hey James,

    Thanks for the fast response!

    Below are the settings:

     

    Host: bjdev01

    Port: 22

    Username: dev

    Password: dev

    Local Path: ../../../../../winnt/TIBRA/clinton.volzke/hitter-release

    Remote Path: /home/winnt/TIBRA/dev/trunk-bin-release

     

    The paths exist, and I can log into the host successfully using those credentials (with the password modified obviously).

    An ssh server is listening on port 22 on that host.

    1. James Dumay

      Local Path: ../../../../../winnt/TIBRA/clinton.volzke/hitter-release

      Ahh this would be why it doesn't work. It needs to be relative to the build directory not just be a relative path.

      Try using a Script task to copy the files into the build directory (something like "cp -R ../../../../../winnt/TIBRA/clinton.volzke/hitter-release ." would do) then change your local path to ".".

      1. James Dumay

        I've also opened up  BAM-12774 - Getting issue details... STATUS  to take another look at the rules surrounding the local path. Lots of people have been troubled with it.

    2. david.s.mittman

      Clinton and James:

      The use of the phrase "relative path" is confusing. Most people think a relative path is one that doesn't begin with a reference to the root of the file system. For instance, a Linux user would say "oh, that path starts with a slash, therefore it's absolute", or "that path doesn't start with slash, therefore it's relative". What the SCP task needs for a local path is a relative path that refers to a file (or directory?) within the current build directory. That's why this kind of relative path won't work: "../../../foo.bar": it's a relative path, but it doesn't refer to a file within the current build directory. I could be wrong here, as I haven't tested this out in the latest version of the SCP task plugin nor have I checked the source code.

  5. Clinton Volzke

    I tried a relative path, but unfortunately it's still not working for me.

    I think error logs are essential for this sort of task, there are a number of things that can go wrong here.

    In the meantime I'll see if I can make a bash script to perform the copy.

    Thanks for your help.

     

  6. Anonymous

    It would be very handy to have the option to select a shared artifact (and not worry about any of the paths / filename pattern complexity).

    1. david.s.mittman

      There doesn't seem to be a feature request already in the system for artifact support. Perhaps you'd like to create one?

      https://jira.atlassian.com

  7. Maurice Romaniuk

    Hi!

    We have been using the builtin SCP task in our nightly builds to transfer loads to our traffic servers. I took a look at those servers and noticed a LOT of TCP connections to the bamboo server that are still in ESTABLISHED state. These coincide with each SCP transfer Bamboo does to those servers (so you can imagine the large number of connections still in place after a few weeks of traffic!). It looks like the TCP connection is not being dropped once the SCP transfer completes. Is this a known issue or has anyone else seen this happening? I can clean them up by rebooting each traffic server but I don't want that maintenance overhead.

    Cheers!

    1. James Dumay

      Hi Maurice Romaniuk,

      Sounds like a bug to me - get in touch with our support team and we look at how to fix it.

      Thanks
      James 

  8. Anonymous

    Is there a way to configure a tunnel (jump box) in SCP and SSH tasks?

    In our case, we do not have direct access from bamboo server to the development server. We have to use a jump box.

    1. James Dumay

      There is no way to do this at the moment, other than use a Script task and manually call SSH or SCP.

      I've raised a new feature request for the tunnelling use case

      BAM-13728 - Getting issue details... STATUS

  9. Rafał Łyczkowski

    Hi,

    1. My SCP Task after accessing a Shared Artifact uploads only first level of files without accessing into the directories in Artifact. In SCP configuration of my deployment there aren't any editable path instead of Remote Path which I've configured well
    2. How can I add a markup of an issue into the comment as "James Dumay" did it? I'm not talking about typing ISSUE-12 (it doesnt provide me this whole element as I want to)