[go: up one dir, main page]
Skip to content

Add target_branch argument to create_merge_request quick action

May be considered a "bug" as missing functionality, but since it's being added to a feature that didn't include this in the original proposal...Feature?

Problem to solve

/create_merge_request only provides an argument for the new branch's name, using the project's default branch as the source of the new branch and target of the MR.

i frequently use this feature, but have to use the button/panel interface instead of the QA because i can't choose the origin/target branch. It only uses the project's default branch. In my case, that's master (i'm open to guidance for a better setup...) so all new MRs would target that. Not desirable. Besides, "default" implies permissible substitutions.

Since i'm running an internal instance of CE, i can't easily coordinate issues in a natural hierarchy, so i work around it with labeling and branch structure. Each release cycle gets a release_## branch targeting master. An Epic becomes a branch targeting the release, then any children of the Epic target the Epic's branch and so on.

Intended users

Mostly intended for project coordinators and developers.

User experience goal

For users who are efficient with typing and make regular use of quick-actions, this change would improve the unified way to type up an issue (or comment) and modify attributes of the issue from one space. It would also streamline creating issues from templates.

Proposal

The /create_merge_request quick action should provide functional parity with the visual component, allowing a user to select both a name for the issue's branch and the branch origin/MR target.

Permissions and Security

This change would not change existing access to the /create_merge_request quick action.

i find it unlikely that specific attributes of a quick action are controllable with Role permissions anyway. Are QAs manageable by Role at all? 😕

Documentation

Current syntax of /create_merge_request:

/create_merge_request [branch name]

Proposed change:

/create_merge_request [auto|branch-name|"branch-name"] [default|target-branch|"target-branch"]
  • An argument value is parsed to the first space character unless enclosed in quotes.
  • Even when enclosed, branch names must still contain legal characters
  • (suggested) Spaces within quotes COULD be converted to legal - or _
  • Examples
    • Automatic selection of new branch name and target (project default) 
      /create_merge_request
/create_merge_request auto
/create_merge_request auto default
    • Specified new branch name, target is project default 
      /create_merge_request new-branch-name
/create_merge_request "new branch name"
/create_merge_request new-branch-name default
/create_merge_request "new branch name" default
    • Auto branch, specified target 
      /create_merge_request auto some-other-branch
/create_merge_request auto "some other branch"
    • Both arguments specified 
      /create_merge_request new-branch-name some-other-branch
/create_merge_request "new branch name" "some other branch"
/create_merge_request new-branch-name "default"
/create_merge_request "auto" "default"
    • INVALID (see links/references) 
      /create_merge_request "" ""
/create_merge_request unprotected new branch
/create_merge_request bad^branch^name worse origin name
/create_merge_request "still^bad^branch^name"
etc.

Note the cases where the argument keywords are enclosed in quotes " ". Like other special markup tags, enclosed strings are treated as literals. Example label: ~"Dumb label!123" does not parse a link to MR 123. If there's really a need to use "auto" and "default" as branch names, so be it.

Availability & Testing

What does success look like, and how can we measure that?

Successful completion provides identical functionality between the visual [Create Merge Request] button/panel and the /create_merge_request quick action.

Links / references