New release directory not updating timestamp

[cmbirk]

I'm running Rocketeer version 1.2.0 and I'm getting an issue when trying to deploy where rocketeer doesn't seem to be updating the release timestamp. The timestamp below is from almost a week ago. I'm obviously able to do a deploy:update to pull changes, but cannot deploy new releases.

fatal: destination path '.../releases/20140408221009' already exists and is not an empty directory.

I've run artisan's cache clear command. I've also gone in to look at how rocketeer is getting this timestamp. It appears it is being done in Traits/BashModules/Core.php in the getTimestamp method. This just runs the date command on the server. Running this manually gives the correct timestamp.

Has anyone else run into this issue?

[chadwithuhc]

I am consistently getting this issue all of the sudden. I didn't haven't up until today, and I upgraded and deployed each day last week.

I'm running 1.2.1

[cmbirk]

I've also tried rebooting the remote server and clearing the composer cache to no avail.

[cmbirk]

Does anyone know if the timestamp is retrieved from the local machine or the remote server?

[chadwithuhc]

I had to remove the folders and re-deploy and it's back to normal.

WARNING: The following commands will remove all files from your deployed folder. Be careful.

Try php artisan deploy:teardown
Then php artisan deploy:setup

And deploy again.

EDIT: I believe I have a safer solution below.

[chadwithuhc]

I've ran into this error again. Here's the steps I took to create it:

• Tried to deploy to my staging server: art deploy --stage="staging" --verbose
• Got the following errors

Cloning repository in "/www/projectname/staging/releases/20140423125123"
[USER@IP] (test) fatal: destination path '/www/projectname/staging/releases/20140423125123' already exists and is not an empty directory.
Unable to clone the repository
fatal: destination path '/www/projectname/staging/releases/20140423125123' already exists and is not an empty directory.
Migrating Database
[USER@IP] (test) Nothing to migrate.
...
Deployment was canceled by task "Deploy"
Execution time: 12.2105s

Please note, todays date is 5/5/2014 and the last time I deployed to the Staging environment was 4/23/14. It is trying to redeploy the last deployment for some reason.

[chadwithuhc]

A temporary fix that worked for me that does not involve the full teardown:

• Remove the app/storage/meta/[application_name].json file which holds the config for the remote connection
• Run php artisan deploy:setup
• Try deploying again

NOTE: I manually removed the directory for the stage that had problems (staging folder) but I think this might work without doing that. Try it without removing the folders first, if it doesn't work, then you might have to remove the folders as well.

@Developer: For the app/storage/meta/[application_name].json I removed, when I looked at the contents it only had the hash property in it. None of the other config data was there. I am not sure what caused this, but I believe it may be the cause of some of these problems?

EDIT: It looks like this might orphan some releases in your stage if you do not delete them manually. This isn't a problem, but old releases not listed in the JSON file might not get pruned properly.

[chadwithuhc]

Could this be due to me switching Git branches? I have a nightly build running through Bamboo which never has this problem, but sometimes I push from my local repo and I never had this problem until I started switching branches.

Just a thought.

[cmbirk]

It does work to run an update instead of a full deployment, but still getting this issue.

[cmbirk]

I think this is a branch issue. I'm noticing that if I always deploy from the master branch, I don't seem to run into this.

[cmbirk]

Although now I'm running into it on the master branch.

[cmbirk]

@Anahkiasen do you have any inclinations as to why this would be happening?

[cmbirk]

I'm actually able to fix the error by running the deploy:flush command that clears Rocketeer's credentials cache.

[cmbirk]

It looks like there might be an issue where the app/storage/meta/deployments.json file is being updated in Server.php:

public function updateRepository($data)
    {
        // Yup. Don't look at me like that.
        @$this->app['files']->put($this->repository, json_encode($data));

        return $data;
    }

I'm assuming that suppression was added for a reason. If there's an error with updating this deployments file, we may not get notified.

[boris-glumpler]

Running into this now, but deploy:flush doesn't do anything.

[boris-glumpler]

When I run deploy with the --verbose flag, then I get following error:

fatal: destination path already exists and is not an empty directory.

Surely, when there is a fatal error, the deployment should be cancelled. It isn't though, so all the messages point towards the deployment being successful. Makes things quite frustrating. Will look more into it.

[Cederman]

I'm getting inconsistent result when both doing a complete deploy and deploy:update. Running the --verbose option shows no error. It says that my app is "Already up-to-date.", but I don't see any changes on the site. Quite frustrating.

[boris-glumpler]

While trying to figure out what the issue was, it suddenly started working again. A couple days later and it all goes wrong again. @Anahkiasen, a little sign of life would be nice.

[Anahkiasen]

Don't worry I'm following this issue closely, I just haven't had much time to get into it lately but I'm not forgetting.

[boris-glumpler]

Ok, thanks for letting me know.

[boris-glumpler]

@Anahkiasen, unfortunately, I didn't find out what caused my issues here and couldn't wait any longer, so moved the functionality across to Laravel Envoy. Cheers for all your hard work on Rocketeer!

[Cederman]

This issue is still bugging all my deploys, the only workaround for me at the moment is doing a full deploy, which takes a lot of time, comparing to an update. Any idea when this issue might be resolved?

[Anahkiasen]

This should be fixed on develop, current/next release isn't cached in a file anymore.

[chadwithuhc]

Awesome! Thanks @Anahkiasen!