Use outside of a git repository?

[tom-lord]

Hi,

I think this CLI tool is brilliant - it's exactly what I'm looking for in order to automate some of the JIRA ticket management.
However, I find it a little odd that a jira-cli must be used from within a git repository. Although this seems like a valuable feature, it seems wrong to force this restriction; especially since many of the commands do not actually involve the use of git.

I would like to decouple the basic CLI tool from git integration. There are various ways of achieving this, but I would propose the following:

• Remove all git-related commands from this gem.
• Create a new gem (jira-git-cli or similar?) which depends on this gem, and extends it with all the various git hooks.

What do you think about this? I would be happy to assist in such a migration task, as I feel the final product would be extremely valuable to the community.

[drn]

Hey @tom-lord,

Totally agree with this sentiment. Rather selfishly, I originally built this completely bespoke to my workflow, rather than be a platform for other's to use. :)

I like your ideas. What I'd like to do is move this project into an organization (maybe ruby-jira) with three discrete projects:

• ruby-jira
  • non-CLI ruby library that is essentially a ruby abstraction of the JIRA API
• ruby-jira-cli
  • CLI powered by this abstraction layer
• ruby-jira-git-cli (not tied to this name...)
  • specific jira-git workflow CLI

If you're interested in helping out with this, I'll set up the organization and the skeleton projects and add you as a collaborator. We can communicate via issues on those projects.

Thoughts?

[tom-lord]

I haven't really dug into much of the implementation details of this gem yet, so didn't really consider your abstraction of the Jira API. Before finding this gem, I first found jira-ruby, which seems to already do what you're proposing as a ruby-jira gem.

Perhaps it would be an even better idea to refactor this code, to use the existing jira-ruby gem rather than reinvent the wheel, so to speak? (Unless this would be a huge amount of work - I can't say at this point.)

Or, just to throw an alternative idea at you, another approach to solve my original problem ("use outside of git") could perhaps be:

• Look for a .jira-cli file in ~/.jira-cli, if none exists in the current location.
• Allow commands to be run from anywhere, i.e. outside a repository.
• Only raise an error upon executing a git-specific command, when outside a git repo.

... Which is OK, but I'm not too keen on this since it still surprisingly couples the gem to git.

For example, with the original suggestion, someone could create a ruby-jira-svn-cli gem, or a ruby-jira-perforce-cli gem, or whatever; the tool wouldn't be specific to git.

Considering the options available, my preferred approach at the moment would be:

1. Create a new project (ruby-jira-cli?), which is a copy of this one.
2. Remove all git-related features from that project, and allow command to run outside a git repo.
3. Look for a .jira-cli file in ~/.jira-cli, if none exists in the current location. Running jira install will save a file in the home folder.
4. Create another new project (ruby-jira-git-cli?), which re-implements those features. (E.g. checking out a branch; it looks like there's actually not very many such features, currently - so this shouldn't be too hard!)
5. Refactor ruby-jira-cli to use jira-ruby.

Does this sound like a good plan to you?

[drn]

This project should definitely be separated into two separated CLIs. One for the git workflow, one as a straight JIRA CLI.

Regarding your approach:
1 / 2 - I don't think there are too many users of this project as it stands. I'd like to convert this project into the non-git-coupled CLI and have a fork of the project be the workflow CLI. I'd like the non-workflow to keep the gem name jira-cli.
3 - This has been a long outstanding TODO that I just haven't gotten around to. For the workflow CLI it makes sense to have both global and project specific configuration. For the non-workflow CLI, we'll only have the root config. 👍
4 - The majority of the commands default to using the current git branch as the ticket. That's handled through an abstraction layer, so there aren't explicit system calls to git spread out around the project. However, it's being used in the majority of commands. It's a default though, so it shouldn't be hard to extract
5 - I like this idea, but I think that can happen after stripping out the git logic. We'll have to investigate how expensive it is to port to a different API backend, but I think that's definitely a good idea.

[drn]

Okay @tom-lord! We're ready to go.

There are now two projects:

• ruby-jira/jira-git-flow
  • will house existing workflow functionality
• ruby-jira/jira-cli
  • the non-workflow CLI

I'm going to close this issue and open separate issues for the tasks that need to be done. Feel free to send pulls for any of the issues. Let me know before you start working any a task so we don't duplicate work.

Issues to work on: #38, #39, #40. Let me know if I'm missing something