Been working through the documentation on git and some of the threads on here, but I am unable to make a deployment, it fails at the cloning git repo point.
I am running a Linode box, and I was able to run the server setup without any issue. However when I come to make the deploy I get a Permission Denied (publickey) error on the task Clone Project Files.
I have set up my key in my GitHub account, I can manually clone the repo via ssh on both the local machine and the server itself. So as far as I can tell I have everything set up. I have added github_ssh_keys: to my staging group_vars.
Iâm a bit stuck for other things to try. Any tips on what might not be working here?
Also would it matter if the repo was on bitbucket as opposed to github? I have tried cloning from both.
You have defined your repo, vs left the default (leaving the default has caused the Permission denied error for a user in the past), and have defined it such that it will clone via ssh (vs https):
Like this: repo: git@bitbucket.org:user/repo.git
Not this : repo: https://bitbucket.org/user/repo.git
Your ansible.cfg isnât somehow missing this ForwardAgent=yes setting.
Your ssh-agent isnât giving you trouble (e.g., like this) â but I doubt it is because if youâre able to manually clone the repo from the server, your ssh forwarding seems to be working.
You might share a verbose log with us (showing error info) by running the long-form deploy command with the -vvvv flag: ansible-playbook -i hosts/staging deploy.yml -e "site=mysitename.com" -vvvv
Thanks for the tips @fullyint. I have it working now.
I think I assumed the problem was something to do with ssh forwarding. So I checked my ansible.cfg to ensure it had the ForwardAgent=yes setting.
It seemed to be the addition of the ssh key to the keychain was the step I needed to do:
/usr/bin/ssh-add -K yourkey
Now that my key is in there, the deploys are working. I found the detail of this in this thread. If you are on OSX then it makes sense to do this.
Just one other thing (this may not be a deploy issue), when I do my deployment, and then check the staging url, the page doesnât render. However I can go into wp-admin and then view the site from there, after that it works fine. Is this normal for a deploy?
@achubb Thanks for telling us how you solved it. âAdding the ssh key to the keychainâ just got bumped a little higher in my mental list of troubleshooting steps for OSX users.
After a siteâs initial deploy, youâd typically see the WordPress install screen at the site url. However, on some occasions Iâve seen the page not load and resolved it by running sudo service nginx reload on the server (or was it sudo service php5-fpm reload ?). For subsequent deploys, the siteâs page always seems to load. I think Iâve heard others mention this but I havenât looked into it.
The initial deploy seems to work fine. I get the WordPress setup page and was able to go through it. It just seems to be on subsequent deploys, sometimes I will visit the url and there is no page being loaded. Normally I can get back into the WordPress admin and then it is fine.
I suspect it is an nginx issue. So I will try restarting it as you suggested on my next deploy.
When the page doesnât load, what is the http status code (e.g., 404, 502, etc, viewable in Chrome dev tools network tab)? You might also check the nginx error log for the site, which is probably at /srv/www/mysitename.com/logs/error.log
@achubb I was just reading about some people getting a white screen after cap deploy because template_root or stylesheet_root wasnât updating (see here and resulting PR here).
Next time you get a white screen after deploy, Iâd sure be interested to know if template_root or stylesheet_root in your wp_options table have the old release absolute path (e.g., /srv/www/example.com/releases/etc) instead of just the relative path /themes.
@achubb I was able to reproduce the issue of the white screen after subsequent deploys, which fixes itself if I navigate to wp-admin then back to the front-end (like you said). I noticed that after a deploy the values for _site_transient_theme_roots in the wp_options table had the old release path and that navigating to wp-admin updated these values to the new release path.
If youâre interested, I invite you to experiment with me on two adjustments:
Add a default post_build_command that replaces the old release path with the new release path in the database:
project_post_build_commands:
- cmd: "composer install --no-ansi --no-dev --no-interaction --no-progress --optimize-autoloader --no-scripts"
+ - cmd: if wp core is-installed; then wp search-replace "{{ deploy_helper.previous_release_path }}" "{{ deploy_helper.new_release_path }}" --skip-columns=guid; fi
Iâm going to test this for a while. @swalkinshaw I anticipate it might be a good trellis default generally, but I think it would also handle trellisâs potential issue with release paths (as seen in bedrock-capistrano).
EDIT: Of course, as with any testing manipulating your dataset, please take a backup of your data first.
Thanks for this. I have changed these settings now and made a deployment to our staging environment, but it didnât seem to make a difference. I will keep those settings in there though and continue to test with subsequent deploys.
The one consistency that I have found is that, disabling the theme and then reactivating it always seems to kick it back into life, so Iâm not sure if that sheds any more light on it.
@achubb Thanks for testing. I came across the âwhite screen after deployâ issue again while testing some different stuff, so I looked into it further.
Ran into the same problem. Is âyourkeyâ my local id_rsa file? The key copied from my Github keys? Neither of those worked for me. I already have keys generated and added to Github.
@fullyint tagging you too since you seemed to help everyone else with this issue too. Thanks in advance.
yourkey to use with ssh-add is the path to the private key on your local machine. For OSX users this is usually at ~/.ssh/id_rsa.
ssh-add â adds private key identities to the authentication agent
This is the private key that forms a pair with the public key you have uploaded to your GitHub account, the same public key that youâve specified in the users hash.
There is more info in the ssh-keys docs, if you havenât seen it already.
Feel free to ask more questions if that info doesnât help resolve the issue.
Makes sense, I was doing the public key instead⌠I got it to deploy but now Iâm seeing a partial white page (http://staging.coreybruyere.com/). And I canât login with the username and password Iâve been using. Any pointers on that and where I can get my staging and produciton credentials? Donât remember ever setting those. Such a tease I finally got a successful deployment only to see a blank page and not being able to login.
Sorry, perhaps I wasnt clear. The staging/production servers can only get a database in a few ways:
a) manually import it
b) Set site_install to true in the Trellis config for that environment, and set all the admin info there as well.
c) donât recall off the top of my head, but there is a database_import directive you can use to point to a database dump
Thanks, I set site_install to true and set my staging db name, user, and pw found in staging/wordpress_sites.yml â wordpress_sites.env to my dev environment credentials hoping itâd replicate my local environment. That didnât work but I was brought to the WP install page on my staging site and now have that up and running, but itâs just my theme with no content.
Whatâs the easiest way to import my db from my local to staging at this point now? I tried searching for the database_import option you mentioned in the forums but didnât find anything. And Iâm not familiar with db or server structure, so Iâm not sure where to even begin on a manual import. Where do I find my local db within my project files? Then what directory does that need to go to on my server? What would you recommend?
Moving your database around is the same whether youâre working on Trellis/Bedrock or a standard WP installation. You export locally, import on staging/production, and do a search-replace of the URL.
