Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,675
Community Members
 
Community Events
176
Community Groups

atlassian/ftp-deploy:0.2.1 uses lots of minutes

Edited

Hello guys!

I'm quite new to Bitbucket pipelines and I recently tried the ftp-deploy (version 0.2.1). After making the initial commit of a single Wordpress installation, the pipeline took 92 min to upload those files to the server.

I know that ftp isn't the fastest way to upload files, but isn't this way to slow?

My configuration is:

pipelines:
default:
- step:
name: Deploy to shared-hosting
script:
- pipe: atlassian/ftp-deploy:0.2.1
variables:
USER: $FTP_USERNAME
PASSWORD: $FTP_PASSWORD
SERVER: $FTP_SERVER
REMOTE_PATH: '/'

Thank you!

EDIT: I tried again - this time only 16 small files changed. After I committed those files, the deployment startet to overwrite every single file on the shared hosting and I stopped the process after 5 minutes.

3 answers

1 accepted

0 votes
Answer accepted

Hey @ericgerhardy. There were service disruptions in Bitbucket recently that could've affected your deployment. I'd suggest that you try to rerun the pipeline to see if the execution time is withing a reasonable time range. If this is not the case, I'd check the size of your repository, as by default, the pipe will upload the entire repo to a remote server. 

Also, since the pipe runs inside docker, the modification times of files isn't preserved. You have to add the --ignore-size option to the EXTRA_ARGS:

- pipe: atlassian/ftp-deploy:0.2.1
variables:
USER: $FTP_USERNAME
PASSWORD: $FTP_PASSWORD
SERVER: $FTP_SERVER
REMOTE_PATH: '/'
EXTRA_ARGS: '--ignore-size'

With this option, the pipe will only upload files that have changed in size.

hey @Alexander Zhukov , thank you for your answer! I tried to rerun it, even tough I added '--ignore-size', every single file was overwritten. 

It seems like ftp-deploy isn't the right choice for pushing committed files from local to the shared hosting. I think I'll try 

image: samueldebruyn/debian-git
pipelines:
default:
-
step:
script:
-
apt-get update
-
apt-get -qq install git-ftp
-
git ftp push --user $FTP_USERNAME --passwd $FTP_PASSWORD ftp://w0120406.kasserver.com/

which works like a charm for some projects, but didn't work with the last one, which brought me to ftp-deploy.

Thanks for your help, I appreciate it!

Hi @Oleksandr Kyrdan ,

pipe rsync-deploy  changes the files and directories permission.

Is there any option to disable that?

 

Cheers

0 votes

@ericgerhardy ,

also, you can use pipe rsync-deploy for your case.

According to Rsync man page:

Rsync is famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination.

Rsync finds files that need to be transferred using a "quick check" algorithm (by default) that looks for files that have changed in size or in last-modified time. Any changes in the other preserved attributes (as requested by options) are made on the destination file directly when the quick check indicates that the file’s data does not need to be updated.


Cheers,
Alex

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events