I have a Gitlab repository containing a WordPress theme - php, js, and css files. My desired result is that when I push a change to the 'main' branch of the repo, the theme files are deployed, raw, without any build or test steps, to my remote server.
I have a .gitlab-ci.yml file set up with 'deploy' as its only step.
The script triggers on 'only: -main' and successfully accesses my remote server via ssh.
What I'm unsure of is how to send the entire raw repository to the remote.
Here is the 'script' portion of my yml:
- rsync -rav --delete project-name/ /var/opt/gitlab/git-data/repositories/project-name/ username#my.ip.add.ress:public_html/wp-site/wp-content/themes/
When the pipeline runs, I receive the following two errors:
rsync: [sender] change_dir "/builds/username/project-name/project-name" failed: No such file or directory (2)
rsync: [sender] change_dir "/var/opt/gitlab/git-data/repositories/project-name" failed: No such file or directory (2)
Is GitLab looking in /builds/ its default behavior? I am not instructing it to do so in my yml.
Is there some other file path I should be using to access the working tree for 'main' in my repository?
Ok, I misunderstood the rsync syntax. I thought the --delete flag included a parameter thereafter, meaning 'delete any existing files in the following directory' rather than what it actually does, which is to auto-choose the destination directory. Once I removed 'project-name/' and corrected the GitLab (origin) file path to '/builds/username/project-name/' the deployment occurs as intended.
Related
I'd like to rsync specified files from a specific server folder to my local directory (in which I am running the command).
However, I'm getting the error failed: No such file or directory (2). There seems to be something wrong with my syntax and I'm not sure its picking up the source directory properly
This is my command...
rsync -az . remoteSite.com::remoteFolder/remoteSubFolder/ --files-from=filelist.txt
filelist.txt, which it seems to be finding, contains filenames within remoteSubFolder
file1.xml
file2.xml
etc
What am I doing wrong?
Thanks to #Gordon Davisson.
I now understand that the full stop represents the local directory and goes after the remote host and directory.
rsync -az --files-from=filelist.txt remoteSite.com::remoteFolder/remoteSubFolder/ .
I have two VM's : dev and prod.
I want to use rsync to copy dump file from prod and then restore it on dev. I'm using this command to copy:
rsync -rave user#ip:/home/user/dumps /home/anotheruser/workspace/someapp/dumps
The same thing successfully copies static files (.html, .css) from another directory, but in this case only the folder itself is created but without the file:
/home/anotheruser/workspace/someapp/dumps
but I'm expecting:
/home/anotheruser/workspace/someapp/dumps/dumpfile
What is going wrong? dumpfile exists there user#ip:/home/user/dumps/dumpfile.
The command you want is probably this:
rsync -av user#ip:/home/user/dumps/ /home/anotheruser/workspace/someapp/dumps/
I've
removed the r because it's implied by the a anyway.
removed the e because that was probably your problem; it requires a parameter that you haven't given.
added the / at the end of the pathnames to make sure they're treated as directories.
I'm using a JFROG cli to download content from an Artifactory. It seems that even though a destination contains same files, cli is trying to download it. If I re-run the command without cleaning the destination folder, I takes the same time.
Is there any option to speedup the process? If destination folder has the same SHA1 file, skip?
Our command (download all folders a* in the repo):
jfrog rt dl --threads=`nproc` repo_name/a*/ $TMP_FOLDER/
JFrog CLI is already skipping download in case of a file existence which is validated using a checksum.
You can see this by setting the environment variable "JFROG_CLI_LOG_LEVEL=DEBUG" and then running same download command again. In the debug log you will see on some files the following line: "File already exists locally" - this means the download was skipped due to a file existence.
The relevant code can be found in GitHub - see the method "downloadFileIfNeeded".
Keep in mind that the CLI still has to get the file info from Artifactory and calculate the local file checksum, so in case of a lot of small files, this won't have a strong effect as on big files download.
Say I have to upload file dir-a/dir-b/dir-c/xxx.txt using sftp
Should I create the target directory first?
Should I open target directory before copying the file?
If have to create this path dir-a/dir-b/dir-c - is it one command or three?
Should I create the target directory first?
Usually yes. SFTP servers usually do not create parent directory. But how hard is it to try first?
Should I open target directory before copying the file?
You do not have to. put command does accept a remote-path, which can be either absolute or relative to remote working directory.
If have to create this path dir-a/dir-b/dir-c - is it one command or three?
These are three commands:
mkdir dir-a/
mkdir dir-a/dir-b/
mkdir dir-a/dir-b/dir-c
I was trying to setting up my AWS beanstalk by following the implementation guide provided by AWS.
But when I got to the "Launch an Elastic Beanstalk Environment" section, this message appeared which basically said the app is not created.
Here's the message:
[Instance: i-088472611e1ef4405] Command failed on instance. Return
code: 1 Output: ln: failed to create symbolic link
'wp-content/uploads': No such file or directory. container_command
2link in wordpress-beanstalk/.ebextensions/efs-mount.config failed.
For more detail, check /var/log/eb-activity.log using console or EB
CLI.
Does anyone have the same problem or know how to resolve this?
Try changing the efs-mount to read the following, the directory clearly doesn't exist so lets just create it.
container_commands:
1chown:
command: "chown webapp:webapp /wpfiles"
2create:
command: "sudo -u webapp mkdir -p wp-content/uploads"
3link:
command: "sudo -u webapp ln -s /wpfiles wp-content/uploads"
2create will create the directory owned by the webapp user and should let you continue.
I just faced the same issue. I am going to assume deploying via the AWS console. That is how I started.
STEP 1: I checked if there was an actual directory wp-content/uploads in wordpress-beanstalk and there was not. It might get created on the first WP upload So, I created the folder, rezipped the application, and deployed to Beanstalk via the AWS Console.
I still received the same error and moved on to step 2
STEP 2: Run EB DEPLOY from the command line
from my local wordpress-beanstalk directory
eb init
choose region (if you already created your app should be this region)
if you already created application choose that wordpress-beanstalk for example
eb use name of your environment
eb deploy
I am not certain that Step 1 is related to Step 2, but was able to successfully deploy facing the same issue using EB CLI.
This is the mounting error of EFS .
EB is using EFS storage to store the wordpress files .
Please check the no.7 in documentation .
"Modify the configuration files in the .ebextensions folder with the IDs of your default VPC and subnets, and your public IP address."
Please edit the efs-create.config file inside the .ebextension folder.
A bit late here so for anyone else having this issue, it's caused when that directory does not exist. Here are some reasons this might happen:
1). WP has not created it - Check manually that it exists.
2). .gitignore - When a .ebignore file is not present, EB uses your .gitignore instead. This can cause the directory to not be uploaded with the EB deploy command. If this is the case, make a .ebignore, EB will start ignoring the .gitignore
3). Document root - If you have modified the document root, to something like /src you have to modify the efs-mount.config file.
##############################################
#### Do not modify values below this line ####
##############################################
container_commands:
1chown:
command: "chown webapp:webapp /wpfiles"
2link:
command: "sudo -u webapp ln -s /wpfiles src/wp-content/uploads"
Even though the file mentions not to modify it, you have to add your document root path in the 2link entry. Change wp-content/uploads to src/wp-content/uploads (replace src with your document root)
Finally, I would not include a command to automatically make this directory, as that only puts a band-aid on the problem.
Hope this helps