Ideas for additional steps, such as linting, etc.

[jshirley]

I'm comparing this tool directly with arc, from Phabricator. In the project directory, you can configure additional behaviors such as running lint and pre/post merge checks.

This ensures that more than just a basic clean rebase and merge into master that nothing breaks (for example, if someone adds a lint rule in master right before you commit, your branch tests will pass but then the master build will fail on the new lint rule).

I see the command workflows, so it seems it wouldn't be too difficult to patch some of this in. Is this something that you would be interested to see in git-reflow?

[codenamev]

We have considered integrating Github's "Merge Checks" they have at the bottom of Pull Requests. I don't think this would be too difficult to add in.

Recently, we refactored the deliver command's merge checks into a single method GitReflow::GitServer::PullRequest#good_to_merge?.

Our long-term goal with git-reflow is to keep the core lightweight. I think this would be great as a gem git-reflow-lint, that takes git_reflow as a dependency and overrides the good_to_merge? method.

[jshirley]

That looks great -- running a local lint as part of the good_to_merge? seems totally reasonable.

Quick implementation question, then I think this can be closed. I see GitReflow.say notice, :notice -- if we emit lint status to that, I assume that is the right output mechanism here?

If we want to have selective output, like when lint fails, using the .say method is also the right way?

[codenamev]

I think so. You can check GitReflow::Sandbox for details on some different tags you can currently pass to say to get an idea for how that works.

[codenamev]

With version 0.8.7 this is now doable using a custom workflow. Official documentation will follow with the 0.9.0 release as we finalize some things, but you can accomplish linting like so:

First create a ruby file for your workflow (this can be located anywhere on your local machine):

class ReflowLinter < GitReflow::Workflows::Core
  def self.deliver(**params)
    # Place your linting code here
    # Any failures should either raise an error or use either `help_now!` or `exit_now!`
    # Docs for the later two methods can be found here: https://github.com/davetron5000/gli/wiki/Error-Handling#custom-exit-codes

    # Now run reflow's deliver command as normal
    super(**params)
  end
end

ReflowLinter

Then set a special git config to register your new workflow:

git config --add "reflow.workflow" "REPLACE_WITH_PATH_TO_REFLOW_LINTER"

Now when you run git reflow deliver it will run your linter before trying to deliver as usual.

I would love some feedback if you do attempt this. I'm trying to figure out the best UX for this. To see how this works, check out the latest Workflow class and reference the existing Core Workflow to see it in use.