flash_flow 1.1.1 → 1.1.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: fe6bb7d56503c667baeff6630b04a356c2c1959e
-  data.tar.gz: cfb7c8792b7556c2bf54e4e47c8fd28d19af9aef
+  metadata.gz: 27e0ad4e0bdac4c870699435930fec56da8d1e6f
+  data.tar.gz: 81f782e7022f09c4814f6488f387767df0c7e042
 SHA512:
-  metadata.gz: dbfe4f236e252efbc73a80607302945aeea1043a41de8fe35eecc10ceae14ec3933d6b6068067753a3f4c9d0b81083a4aac8fc90d885182a71073641c1f8b943
-  data.tar.gz: 116c96cfea5b0977a52250740e3dafc27e576952b4926ccda14976dbee1c90d700a0e59f89ff08ab3c3ec4f6653af0312f49ae0aa959a8d98f6f90cbf09021de
+  metadata.gz: 7e7c38d6703b872e27d45202122a2e747a1fa9aca61ae80937c78cea2b932dee0587eaa963b8a09ac3a986f70aca121c6142970b67808c6bfbb335afddadc480
+  data.tar.gz: f83076ce192c2bb9987c883e10a6ea1e91be261bfc6c7b6b1f5cf78c3ad9b14433bd25a849ec5412a6ee70e7e9dfff9613ac4743f37ed84d7f443222fe2b7d9a

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    flash_flow (1.1.1)
+    flash_flow (1.1.2)
       hipchat
       octokit
       pivotal-tracker

data/README.md

@@ -36,14 +36,16 @@ What that will do (once your application is properly configured) is:
 3. Get your list of pull requests from github (or use the saved list, more on that later)
 4. Filter out any "removed" branches
 5. Merge the rest into the newly created `merge_branch`
-6. Force push the `merge_branch` to the `merge_remote`
+6. Push the `merge_branch` to the `merge_remote`
+7. The `merge_branch` is now a merge of your master branch plus all of your pull requests.
 
 ### Notes
 
 1. Step 1 will not push your branch if you're on either the `merge_branch` or `master_branch`, but it will
 still merge all the other branches and push the result.
-2. flash_flow uses your local git repo. It resets everything back to the branch you started in, but you should not do
-anything else in your repo while it's running because lots of mayhem will ensue.
+2. flash_flow creates a copy of your local git repo. The copy lives in /your/repo/dir/../.flash_flow/.
+That's where it merges all the code and pushes to the remote from. This "shadow" directory is used so
+that your local git repository is still available for your use while flash flow is running.
 
 
 ### Configuring a lock
@@ -60,20 +62,25 @@ In step 1 after your branch is pushed, a pull request into `master_branch` will
 add the "do not merge" label to a pull request, it will be excluded from the `merge_branch`. This is extremely
 useful whenever one of your co-workers breaks the build, you can either run `flash_flow --no-merge` from their
 branch, or go directly to github and add the "do not merge" label and then re-run flash_flow from your branch.
+
 To use github as your source of merge branches you have to configure it with the class name, github token and
 repo, your master branch name and both the unmergeable label and do not merge label, which must exist on github.
 The unmergeable label is added to a pull request that has a conflict that can't be resolved and is therefore
 excluded from the merge branch.
 
 ### Configuring an issue tracker
-We use Pivotal Tracker. Anytime flash_flow is run, all the branches that get merged, if they have any stories
-associated with them (added via the `--stories` option), those stories will transition to "finished" if they
-were previously "started". When code deploys to our review environment, our deploy script runs
-`flash_flow --review-deploy`, which transitions stories associated with merged branches from "finished" to
-"delivered". At the same time, for a branch that has been removed ("--no-merge"), if the story is "delivered"
-it will transition back to "finished". In addition, as part of our production deploy
-script, we run `flash_flow --prod-deploy`, which takes all the stories that are newly in the `master_branch`
-and adds a comment "Deployed to production on 12/25/2015 at 11:11pm". So using the story option can be handy.
+We use Pivotal Tracker. When we have finished work for a story on a particular branch we run
+`flash_flow --story <story_id>`, which will transition all of those stories to "finished" if they were previously
+"started".
+
+When code deploys to our review environment, our deploy script runs `flash_flow --review-deploy`, which transitions
+stories associated with merged branches from "finished" to "delivered". At the same time, for a branch that has been
+removed ("--no-merge"), if the story is "delivered" it will transition back to "finished". This means that the only
+buttons that have to be manually clicked in tracker are "Start" and "Accept/Reject".
+
+In addition, as part of our production deploy script, we run `flash_flow --prod-deploy`, which takes all the stories
+that are newly in the `master_branch` and adds a comment "Deployed to production on 12/25/2015 at 11:11pm". Tracker
+doesn't support a real state for "In production", so for us this comment serves as that state.
 
 ### Configuring hipchat
 When a branch other than the one you're on doesn't merge cleanly and can't be fixed by rerere (more on that later
@@ -123,14 +130,22 @@ If you have Pivotal Tracker configured it will look at all stories associated wi
 deployed to `acceptance_branch` it will mark any finished stories as delivered. This is best used right after every
 deploy to your acceptance environment. The acceptance branch will not be re-built in this case.
 
-### Merge conflicts
+#### --resolve
+Launch a bash shell to save your conflict resolutions. If your branch didn't merge the last time you ran flash flow
+you'll run this command. This drops you into bash where you can save your resolved conflicts, then those resolutions
+will be remembered the next time you run flash flow.
+
+#### --resolve-manual
+Print instructions that will show you how to resolve your merge conflicts without using flash flow's version of the
+shell. If you don't use bash, or flash flow does odd things to your bash config, this is the way to go.
+
+### A note about merge conflicts
 When we first started using flash_flow, if your branch had a merge conflict you were out of luck. You had to wait for
 the branch that you were conflicting with to be merged to master, merge master into your branch, and then try again to
 get your code into the merge branch.
 
-Then we discovered git rerere, which is the coolest feature of git that almost no one seems to have heard of. Googling
-it turns up a few really good resources on how it works, but in one sentence or less what it does is remember how you
-resolved conflicts and apply those patches.
+Then we discovered git rerere, which is the coolest feature of git that almost no one seems to have heard of. Basically
+what rerere does is remember how you resolved conflicts and auto-apply those patches when it notices the same conflicts.
 
 If your branch has a conflict with the `merge_branch` flash_flow will look for a rerere patch and apply that if it
 exists. If it doesn't, flash_flow will not merge your branch (but will continue merging all the others), and it will

data/lib/flash_flow/data/base.rb

@@ -44,7 +44,10 @@ module FlashFlow
 
       def backwards_compatible_store
         @backwards_compatible_store ||= begin
-          hash = @store.get
+          hash = in_shadow_repo do
+            @store.get
+          end
+
           hash.has_key?('branches') ? hash : { 'branches' => hash }
         end
       end
@@ -53,6 +56,13 @@ module FlashFlow
         Collection.from_hash(@git.remotes, backwards_compatible_store['branches']).to_a
       end
 
+      private
+
+      def in_shadow_repo
+        ShadowRepo.new(@git).in_dir do
+          yield
+        end
+      end
     end
   end
 end

data/lib/flash_flow/shadow_repo.rb

@@ -29,12 +29,17 @@ module FlashFlow
       end
     end
 
+    FLASH_FLOW_BASE = '.flash_flow'
     def flash_flow_base_dir
-      @flash_flow_base_dir ||= current_dir + "/../.flash_flow"
+      if current_dir =~ /\.flash_flow/
+        "#{current_dir.split(FLASH_FLOW_BASE).first}#{FLASH_FLOW_BASE}"
+      else
+        "#{current_dir}/../#{FLASH_FLOW_BASE}"
+      end
     end
 
     def current_dir
-      @current_dir ||= Dir.getwd
+      Dir.getwd
     end
 
     def flash_flow_dir

data/lib/flash_flow/version.rb

@@ -1,3 +1,3 @@
 module FlashFlow
-  VERSION = "1.1.1"
+  VERSION = "1.1.2"
 end

data/test/lib/test_deploy.rb

@@ -75,8 +75,10 @@ module FlashFlow
     def test_check_out_to_working_branch
       @deploy.stub(:in_shadow_repo, true) do
         @deploy.stub(:check_repo, true) do
-          Lock::Base.stub_any_instance(:with_lock, -> { raise Lock::Error }) do
-            assert_output(/Failure!/) { @deploy.run }
+          @deploy.stub(:check_version, true) do
+            Lock::Base.stub_any_instance(:with_lock, -> { raise Lock::Error }) do
+              assert_output(/Failure!/) { @deploy.run }
+            end
           end
         end
       end
@@ -99,13 +101,12 @@ module FlashFlow
     end
 
     def test_merge_conflict
-      data.expect(:mark_failure, true, [@branch, 'some_sha'])
+      data.expect(:mark_failure, true, [@branch, nil])
 
       notifier.expect(:merge_conflict, true, [@branch])
 
       merger
           .expect(:do_merge, :conflict, [ false ])
-          .expect(:conflict_sha, 'some_sha')
 
       BranchMerger.stub(:new, merger) do
         @deploy.git_merge(@branch, false)

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: flash_flow
 version: !ruby/object:Gem::Version
-  version: 1.1.1
+  version: 1.1.2
 platform: ruby
 authors:
 - Flashfunders
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2015-10-28 00:00:00.000000000 Z
+date: 2015-10-30 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: octokit
@@ -164,6 +164,7 @@ files:
 - lib/flash_flow/shadow_repo.rb
 - lib/flash_flow/time_helper.rb
 - lib/flash_flow/version.rb
+- log/.keep
 - test/lib/data/test_base.rb
 - test/lib/data/test_branch.rb
 - test/lib/data/test_collection.rb