Preventing Corrupted Workspace

[brycefisher]

We use shipit and really like it. Today, we ran into a bit of an edge case, and I'd like to suggest a change OR get advice on how to override the default deploy:fetch task.

What happened was this -- somehow my workspace was altered. Grunt-shipit executed during deploy:fetch a git checkout , but this kept my working directory dirty.

I'd like to insert an extra local command git reset --hard HEAD after the checkout but before the rsync. Would you be interested in having that in this project generally or is more of an edge case for my particular project?

[brycefisher]

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

[gregberge]

@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?

[brycefisher]

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.

[gregberge]

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

[brycefisher]

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

[gregberge]

@brycefisher good!

[timkelty]

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.

[brycefisher]

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 :-)

[gregberge]

@brycefisher good thank you

[timkelty]

Thanks @brycefisher !

[timkelty]

@neoziro Can we get a release with this?