Fixing whippet deploy #25

Closed
tomdxw opened this Issue Jul 9, 2015 · 8 comments

Projects

None yet

2 participants

@tomdxw
Member
tomdxw commented Jul 9, 2015

This proposal should fix #1 and #2.

Here's the current logic:

//    1. Clone WP
//    2. Delete wp-content etc
//    3. Make sure wp-content is up to date
//    4. Copy our wp-content, omitting gitfoo
//    5. ?? Theme/plugin build steps ?? (Makefile-esque thing?)
//    6. Symlink required files from shared dir

We should change that to be:

  1. Clone WP
  2. Delete wp-content etc
  3. Make sure wp-content is up to date (merely fetch, checkout the branch, and run "git clean -dxff" to remove all untracked files in the workdir - this will include submodules that have been removed)
  4. Copy the entire workdir, not just the wp-content directory
  5. In the copied workdir: git submodule update --init --recursive
  6. In the copied workdir: Install plugins
  7. (In future, maybe) In the copied workdir: run theme/plugin build steps
  8. In the copied workdir: Remove gitfoo
  9. Move wp-content to the appropriate place, and delete the copied workdir

This will mean that we're starting out with a totally clean workdir, so plugins should not persist and there should be no issue moving between plugins and submodules.

@harry-m Does this sound reasonable?

@tomdxw tomdxw added the bug label Jul 9, 2015
@harry-m harry-m was assigned by tomdxw Jul 9, 2015
@harry-m
Member
harry-m commented Jul 14, 2015

Why not do steps 5, 6, & 7 in the workdir, and then copy and remove gitfoo?

@tomdxw
Member
tomdxw commented Jul 14, 2015

@harry-m Because then somebody will have to SSH into the machine and rm -rf the original workdir and run chef-client every time we want to delete a submodule or plugin.

@harry-m
Member
harry-m commented Jul 16, 2015

Must be missing something. If we have a repo that is always checked out, from which deploys are generated, why wouldn't we make sure that repo is definitely in the correct state and then generate the deployable site from that? Why is it necessary to do the updates in a copy? Can't we just git clean -dxff in the always-checked-out repo?

@tomdxw
Member
tomdxw commented Jul 20, 2015

@harry-m I obviously wasn't thinking when I said that. Yeah, the clean -dxff command will mean we can do those commands in the main directory.

So with that in mind, maybe all we need to change is to add a single line which runs "git clean -dxff" before pull/submodule update/etc.

@harry-m harry-m assigned tomdxw and unassigned harry-m Jul 22, 2015
@harry-m
Member
harry-m commented Jul 22, 2015

Swish. Let's do it.

@harry-m
Member
harry-m commented Mar 31, 2016

There's an open pull request on #34. Does it resolve all the problems noted in this issue?

@harry-m harry-m added this to the Sprint - April 2016 milestone Mar 31, 2016
@tomdxw
Member
tomdxw commented Mar 31, 2016

That's the intention, yes. Needs some more work though.

@harry-m
Member
harry-m commented Mar 31, 2016

Ok, cool. I'll close this one then.

@harry-m harry-m closed this Mar 31, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment