Preventing Corrupted Workspace about shipit-deploy HOT 11 CLOSED

Here's a bit of code we're using to workaround the deploy:fetch using an old version of grunt shipit:

// Make sure the working tree is clean before fetching/merging
var workspace = grunt.shipit.config.options.workspace;
if (typeof workspace !== 'undefined') {
  if (grunt.file.exists(workspace)) {
    grunt.log.writeln('resetting preexisting workspace ');
    grunt.shipit.local('git reset --hard HEAD', {cwd: workspace});
  }
}

We put this in a grunt task called setup then we run deployments like this:

$ grunt setup:qa shipit:qa deploy

This is a quick hack, but it seems to work for our case (haven't tried the shallowClone option). To verify this:

1. Run your deployment as normal and ensure that the workspace is in place
2. Modify a file in your workspace
3. Run only the grunt setup task
4. git status from inside your workspace should now show your workspace is clean

from shipit-deploy.

@brycefisher I know some issues when the repository stay dirty, implementing a hard reset will fix that for sure. I just want to be sure that it will not have side effects. I am pretty sure that git reset --hard doesn't remove any files (node_modules, etc..) but I am not totally sure. Do you think it's completely safe to do a git reset --hard?

from shipit-deploy.

That's a great question! Yeah, we need to be sure before making any changes. So, I just did an experiment on my machine:

#!/bin/bash
echo Create a dummy project to experiment on
mkdir -p /tmp/git-reset-test/ && cd /tmp/git-reset-test/
npm install --save lodash
echo "The README" > README.md

echo Setup git
git init
echo "node_modules" > .gitignore
git add . && git commit -m "initial commit"

echo Dirty the working tree
touch extra_file.txt
rm README.md
git status

echo Reset hard
git reset --hard HEAD

echo Verify Project State
ls -lah
cat README.md

At the end of this:

• node_modules directory is unchanged
• the README.md is "undeleted"
• extra_file.txt is unchanged since it wasn't in version control to begin with

I imagine that's what you want to have happen before deployment most of the time.

from shipit-deploy.

@brycefisher OK good, we need to add this step to the deployment process, do you want to make a PR?

from shipit-deploy.

Yeah! I'd love to. It might take me a take or two put one together, but I'm happy to contribute this enhancement.

from shipit-deploy.

@brycefisher good!

from shipit-deploy.

Any traction here?

It seems like it would be a good idea to also include something like a deploy:clean-workspace.

It seems like inevitably, something gets messed up in your workspace and it would be nice to delete it with a task rather than rm -rfing stuff.

from shipit-deploy.

Hah, "a week or two" has become 2 months. My apologies @timkelty. I've just put together a PR. We'll see if the tests pass :-)

from shipit-deploy.

@brycefisher good thank you

from shipit-deploy.

Thanks @brycefisher !

from shipit-deploy.

@neoziro Can we get a release with this?

from shipit-deploy.