How to automatically set a label on each new issue at creation?

How to Use GitLab
1

When a new issue is created, it has no labels. I would like to have every issue have the triage label on creation, so that it can appear in its own list on the issue board, and be moved to the appropriate position in the “open” list from there.

https://docs.gitlab.com/ee/user/project/description_templates.html suggests a solution, but this is not available in GitLab CE. I don’t suppose this feature is planned to be available in CE any time soon?

Alternately, is there a way to make newly-created issues appear at the top of the “open” list by default, rather than at the bottom? That would enable me to see them and move them to an appropriate position, whereas adding at the bottom means they don’t get seen.

It’s a pain to have to scroll all the way to the bottom to move new issues, especially since the list only loads a page at a time (and you can’t simply press ⌘↓ to get there — you have to scroll).

(This is a personal project — there’s no way I can justify a subscription just to add this feature :grinning:)

1 Like
2

I’ve worked around this for now by adding a triaged label and using that as the “open issues” column to work from, with “open” meaning “not triaged” — but I’d still like to know if there’s a way that doesn’t need this hack…

3

Hi,

the default issue template may add more convenience, but the real thing you are asking for are issue actions. We use that for our templates as well, check in here for example at the bottom:

https://gitlab.com/gitlab-com/marketing/corporate_marketing/corporate-marketing/-/raw/master/.gitlab/issue_templates/technical-evangelist-request.md

/label ~"tech-evangelism" ~"TE-Request::New" ~"TE-Request-Type::External" ~"TE-Content::new-request"

/cc @abuango @pritianka 
/assign @abuango

Cheers,
Michael

1 Like
4

I’m not asking for issue actions, because I already use issue actions.

What I want is to not have to type /label ~triage on every issue, and thus lose track of issues where whoever’s entered it has forgotten to do so.

I want to have that text already inserted at the bottom of the issue when it’s created, so that an issue creator will have to make a deliberate effort to remove it. Computers are for automating tedious and repetitive actions so that we don’t have to keep doing them ourselves, no? :slightly_smiling_face:

5

Hi,

sorry, that was not clear to me from your initial question. I was under the impression that you’ve researched on the topic, and now have found the default issue templates :slight_smile:

I’m not sure about the behaviour of the aforementioned default issue templates, but I could imagine that with more than one issue template there’s still a chance for the user to make a mistake.

Yep, and the use case where you are coming from is quite often desired. Issue templates can be one way of helping the users to follow the “standard procedure”. There are other approaches too, sometimes hard to find. Good that we have this platform :wink:

The power of open source and transparency is that you can follow how others solved the problem, and often chime into source code and configs too. In addition to that, GitLab’s API allows you to manage and retrieve nearly everything you need.

A while ago I was asked about persisting the protected branches in the project settings, just because maintainers may overrule that. In the end, we defined a cronjob talking to the REST API in the customer environment, thinking about hardening flags as feature request :100:

With regard to issue templates, I’d like to add my experience too. In the past 10 years in open source projects I have seen lots of users who do not understand the Markdown text inside, and just mark all and remove it. Or do funny things with it and you always need to do manual triage afterwards.

In order to prevent the dependency on the issue content on its own, I would suggest another approach.

Automated Issue Triage

The user does nothing here, it all happens in a scheduler script.

  • The issue gets created, timestamp for the creation date
  • Each day a script checks runs and checks:
    • creation_date > now - 1d
    • Optional: count(comments by team members) == 0
    • needs_label(“needs-triage”)
  • If the conditions match, the script sets the label

Technical Approach

In order to avoid curl and bash, using the Python API bindings might be useful.

Examples

GitLab-org Bot

On GitLab.com there is a bot which adds labels and does other tasks for all incoming issues. It is a complex example but you’ll get the idea of using CI/CD as a scheduler to run a script.

Our triage ops team uses the gitlab-triage Ruby project to specify certain policies and also use plugins.

Might be worthwhile to checkout it out for requirement too: GitLab.org / ruby / gems / GitLab Triage · GitLab

gitlab-triage used at GNOME

Gnome uses the mentioned gem and has incorporated their own policies.
The blog post is really detailed and should help getting things going: Issue handling automation for GNOME

Technical Evangelism Bot

We wanted to have a bot which creates issues for us on a specific date, and also creates a weekly issue summary. Issue triages are on our list - it is not yet done though. @abubakar - please jump in and share some technical details after your vacation, thank you! :sunglasses:

Cheers,
Michael

1 Like
6

Thanks — that’s very comprehensive!

A script that runs overnight isn’t really an option, as that adds 24 hours to the processing of each issue. I take it there isn’t a way to run a script as a post-issue-creation hook?

I think my main issue was that I’ve already added a default.md template — but that only causes a Description dropdown to appear on the issue creation page. And now, instead of typing /label ~triage, the user needs to resort to the mouse or navigate a dropdown in order to select the default template — because I can call it default, but I can’t make it default. Which still means that they can create an issue without applying the template.

https://docs.gitlab.com/ee/user/project/description_templates.html#setting-a-default-template-for-merge-requests-and-issues--starter says that making a template default is only available at Starter/Bronze level, which seems rather petty. My question was really a request for this functionality to be made available to CE users, even if the fancy UI was replaced by “you must call your template default.md for it to be the default”…

7

Hi,

You could also run the job every 5 minutes, that is more or less a consideration how often you’d want to run it. One thing which comes to mind - I get a lot of issue update notifications during the day. If those needs-triage updates hit me every time, I would get distracted - so I like that my colleagues prefer 24h.

Still, there’s no definite interval - I’d say, try it out with 1h and see how it goes :slight_smile:

I’ll be honest - I don’t know if that’s going to happen following the decisions on paid features. It’s my 3rd month and I am still learning :slight_smile:

Your idea with removing the UI parts though is an interesting one. Mind opening an issue where our product managers can jump in and weigh your proposal? :sunglasses:

Ok, understood, thanks. This adds more clarity on your use case. Unfortunately I cannot recommend anything else than the above for now, as an immediate solution.

Just googled for another term, this feature request would also be worth commenting & upvoting: Default Label for all issues (#15028) · Issues · GitLab.org / GitLab · GitLab

Cheers,
Michael

8

Your idea with removing the UI parts though is an interesting one. Mind opening an issue where our product managers can jump in and weigh your proposal?

Thanks — I’ve added a feature request at Allow `issue_templates/default.md` to be the default issue template at Core/Free level (#218658) · Issues · GitLab.org / GitLab · GitLab, and commented on/upvoted the other issue.

In the meantime, the workflow I have using a triaged label once something’s been triaged seems to be working OK :slightly_smiling_face:

1 Like