Why deploy_revision cannot checkout the git project's sub folder after manually deleting it

Hi All,

I’m using deploy_revision to checkout git project. After manually deleting
one of the sub folder of the project, and run the recipe again, the deleted
folder hasn’t been recovered.

Recipe: default.rb

deploy_revision "/root/tmp" do

      repo ‘https://giturl/test.git’

      keep_releases 1

      symlink_before_migrate.clear

      create_dirs_before_symlink.clear

      purge_before_symlink.clear

      symlinks.clear

      enable_submodules true

      shallow_clone true

      action :deploy

end

The first run will download the project into /root/tmp/shared/cached-copy
and /root/tmp/releases/ab3606f33b97653bf98f6f7c8c1b76b18b9c3561.

And the project structure:

  test1/

            a.txt

  test2/

            b.txt

Now delete the directory /root/tmp/shared/cached-copy/test2, run the recipe
again, the test2 directory won’t be downloaded again.

But in the release folder
/root/tmp/releases/ab3606f33b97653bf98f6f7c8c1b76b18b9c3561 the test2 is
still there. So I delete it as also and run the recipe again.

Finally neither the test2 folder in releases nor in cached-copy has been
recovered no matter how many times the recipe is run.

How can I use this chef resource to get the deleted folder back?

Thanks & Regards

Jason

It doesn’t check that the working directory is clean. The cloned repository
is still at the correct revision but you have unstaged changes (deletions)
that would need to be manually reconciled. Think about this from the other
angle, if you had added files to the directory, would you expect chef to
remove them?

You could add a notifies to that block that runs a bash script of git add . && git reset --hard head only_if git diff --exit-code (returns 1 if
there’s unstaged changes) to make the current state of the repository match
the remote’s tip but that seems really hacky.

Thanks Daniel. That works.

Since deploy action always needs to be executed to synchronize remote code change, I add the execute resource before the deploy_revision as you suggested and it works well.

Thanks.

Regards
Jason