JamesGlover / test_hub

A github repo for playing around with github features
MIT License
0 stars 0 forks source link

Github CLI develop functionality #3

Open JamesGlover opened 8 months ago

JamesGlover commented 8 months ago

Outline

As a developer I want to test the existing gh branch creation functionality So that I can make sure I don't build a redundant feature

Background

A few years ago I wrote a series of bash scripts to assist with my workflow. At the time I couldn't find native support for the following functionality.

Now I want to explore using Go to add similar functionality as an extension, primarily as a learning exercise. However it is important that this exercise produces something of real value.

This issue provides a basis for exploring the CLI functionality.

JamesGlover commented 8 months ago

gh develop - Creates the branch and links it to the issue. It lets me customize the name, but no documentation of the way to configure the pattern. The issue itself doesn't change its state.

JamesGlover commented 8 months ago

https://github.com/cli/cli/blob/trunk/api/queries_branch_issue_reference.go#L15

This gets passed branchName from the CLI arguments, which defaults to an empty string. In the event the option isn't provided, it is the GitHub API that sets the default branch name.

I'm happy enough with this behaviour for an MVP, especially as customizing the branch name more fully would depend on additional configuration, which adds its own research spike while I look into the conventions used here.

JamesGlover commented 8 months ago

Had a quick check of branch naming options at the repository level, as this would be the 'correct' home for the feature - as ultimately naming conventions are probably something you'd want to configure at the organization/repo level. Lots of requests for that functionality here:

https://github.com/orgs/community/discussions/12290

JamesGlover commented 8 months ago

I'm realising that option 1 can't easily give 'out the box' sensible behaviours:

  1. Create a branch - Easy enough, especially if we allow custom names / default names only in the first instance
  2. Assigning a user - Again easy enough
  3. Marking the issue as 'in progress' - This is somewhat trickier, as the 'correct' action is dependent on the configured project workflow. What's worse, is that is no guarantee that this is necessarily going to even be the same for all issues in a repo, or indeed even all projects attached to a given issue. This means we either need per-project configuration, or else force the state to be provided with each command.

However, GitHub have completely redeveloped their project handling since I last delt with it in anger, so it may be that there are better tools available. Or, this functionality is better automated elsewhere, such as an action triggering on branch creation.

JamesGlover commented 8 months ago

Projects do provide the ability to customize workflows, but I haven't found a 'branch created on issue' trigger there. This feels like the correct 'home' for the functionality.

Projects do let you add arbitrary fields, which would allow configuration of a default 'WIP' state, but this doesn't feel like a sensible option to use for a general purpose CLI tool.