Quick Actions
Welcome to Tanuki Tuesday, where I look at the features offered by GitLab.
This week I am looking at quick actions, and how they can increase your productivity. Get more done in less time by not leaving the issue description or comment box.
I am focusing this article specifically on actions within issues. There are some quick actions which can be used in Merge Requests or within Epics
What Are Quick Actions?
Quick actions replace the need to stop what you are doing in the markdown editors to click on elements of an issue, by letting you perform the actions within the editor.
Things like assigning issues to people, adding labels, setting the issue weights, milestones, and epics can all be done through quick actions.
Some of those are only relevant at specific subscription levels. But if the feature is available for your project then, once you get used to them, I'm sure you'll love them.
Quick actions have been built, it seems, with Newton's third law of motion - "For every action, there is an equal and opposite re-action".
Basically, if you can add something to an issue via a quick action, you can also remove it.
Uses of Quick Actions
When adding some meta information to an issue, such as a label, you normally do this by clicking on a drop-down select box, search for the label you want, and click it.
To remove a label, it's the same process. Search (using the same drop down), and click to remove it.
If you are adding, removing, or changing a lot of labels, this can be time intensive.
Labels
Labels are where I use quick actions the most. I rarely use the drop-down to select a label.
Prior to the image above, I don't recall the last time I used it. I've completely trained myself to do it via quick actions.
Adding a label to an issue using quick actions is as simple as starting a line in the editor window with /label once that's in place, you can search for labels by adding ~.
When the list of labels to select is available, you can use the up/down arrows to select, and enter to auto-complete.
If there are spaces in the label name, the label will have quotations added automatically.
You don't need a new line starting /label for each label you wish to add. Just add them all on the same line.
If you are using scoped labels as part of your workflow, then these are available as you would expect.
They will remove the previous label of the same scope (if applicable) and replace it with the one from the comment/issue edit box.
If you don't have scoped labels as part of your subscription but still need to remove label(s) from an issue, you can use /remove_label in the same way as /label.
/unlabel is an alternative to /remove_label and does the same thing so fewer characters are needed, if you want to save time.
That, and not everyone is used to typing underscores.
Milestones and Epics
Rather than finding the right milestone or epic to create the issue from, quick actions are available to add and remove those.
By starting a line in the description with /epic &, you can add the issue to an epic as soon as it's saved.
Similarly, a line starting /milestone % will let you search and use auto-complete for the milestones.
Closing issues
More often than not, this will be done from the comment part of an issue. Why? because you aren't going to create and close an issue at the same time, probably!
Chances are, you'll add a comment as to why the issue was closed, so there's a history of the decision being made.
Yes there's a "Comment & close issue" button right below the comment button, but that requires the use of Tab or a mouse to get there.
Some people (and I am one of them) will use keyboard shortcuts (more about those another time) to submit the comment (Ctrl+Return if you are interested).
Once you are in the comment box, you add your closure reason, add a new line, type /close, then submit. Done, issue closed. No need to leave the comfort of the keyboard.
Issue and Merge Templates
I've previously covered issue templates and the benefits they bring.
Even better is when they are combined with quick actions.
Adding quick actions to the templates allows the meta data about an issue be set correctly from the start.
When you've got a workflow which requires issues to be categorised in such a way which is known to mean it needs attention, then getting it right early is important.
My workflow for bugs being raised, for example, is for it to have scoped labels for Issue Type::Bug, Bug::New, Priority::TBC, and Severity::TBC.
These have colouring such that I can quickly see them on the issues list, but they also appear in custom issue boards.
Asking someone to remember to add those every time is going to result in errors and things being missed.
Adding them to the template means they don't need to remember; they simply submit the issue and it's added for them.
The template contains the following line, and they are added when the issue is created.
/label ~"Issue Type::Bug" ~"Bug::New" ~"Priority::TBC" ~"Severity::TBC"
Different issue templates may relate to specific areas of the system. It doesn't matter if it's front-end and back-end, or as granular as modules in a system e.g. Products Bug.
Those issues might be better placed to be triaged by a specific person or team. This is where /assign might be included in a template.
Sure, you might be able to remember who looks after a specific team or set of issues, but what if they leave, or swap teams, or someone else is triaging those issues?
You might not be aware of that change, and things might be left to one side until someone picks up those issues.
Setting the /assign in a templates allows for the direction of issues to be kept up-to-date quickly and easily.
Change the template in the default branch, and it's done. New issues are assigned to the new person.
Summary
There's a lot more which can be done with quick actions, and the full list of them is available within GitLab's quick action documentation.
Some of them can only be used within certain contexts, e.g /wip can only be used within a merge request, but some are useful in issues, merge requests and epics.
I don't believe the are a great learning curve, but what they bring is, for me at least, a lot of time saved from clicking all over the screen.
There's no switching back-and-forth between keyboard and mouse to select things and add the meta information to a record.
Even more time is saved when these issues are included within issue templates.
There's no need to remember who needs to be assigned to triage an issue, or what labels need to be given by default to issues.
Reduced cognitive load; reduced stress.
Next time you're working within GitLab and need to add some meta information, give quick actions a try.
Top comments (0)