One particular feature I am interested in is automatically removing (or adding) certain labels when issues are closed. For example, it would be nice to remove an "In Progress" label when the issue is closed.
You can define the triage rules in a YAML file and the script is run as a scheduled pipeline.
Note: We did this as an external tool because we really needed to address the current state of our issue tracker (https://gitlab.com/gitlab-org/gitlab-ce/issues) but I definitely think it should be a GitLab feature since issue/MR trackers are at the foundation of any (open source) project.
That being said, I think the final solution should probably includes two things:
a CRON-like script (we could use scheduled pipeline for that) that would tidy/cleanup the tracker regularly
a bot that would react to events (new issue/MR, new labels etc.)
@rymai@markglenfletcher : If this is a gitlab feature, I'm thinking of two generic use cases / features:
Fully-automated with configurable settings. E.g. auto-close issues with no activity if they are stale for x number of days, where x is configurable.
Build an operational feature into say, the issue list. So you can have the ability to search/filter by certain criteria of activity (stale for certain amount of days), and then a user could just use bulk edit to close all those issues. So anybody with correct permissions could do "cleanup" whenever they wanted to, giving them more control.
Just for GitLab, what would make more sense for us?
For the GitLab projects, we want to publish our Issue tracker and Merge Request management policies publicly and automatically enforce them.
We have opted to move forward with a notify then close approach. This allows the reporter to determine whether the problem persists and update the issue, without updates we proceed to close after a configured amount of time. This seems like the softer approach but it also allows us to follow up on issues that we may have missed due to volume.
Either way, I think that the introduction of additional filters for the web interface and api would be beneficial for both Issues and Merge Requests.
Fully-automated with configurable settings. E.g. auto-close issues with no activity if they are stale for x number of days, where x is configurable.
I guess this is what I was suggesting with:
a CRON-like script (we could use scheduled pipeline for that) that would tidy/cleanup the tracker regularly
The configuration could be done in YAML (at first?), or in the UI (a bit more complex to implement since it involves UX, UI, frontend).
I think we may be able to use the current triage project for this, with:
YAML support only at first
Manual scheduled pipeline creation at first
Then, later we could build a UI that would generate the YAML dynamically, and use a "hidden" scheduled pipeline instead of having to create it manually. I've detailed how to use the triage project as a GitLab feature here: https://gitlab.com/gitlab-org/triage/issues/14#note_41293856
Build an operational feature into say, the issue list. So you can have the ability to search/filter by certain criteria of activity (stale for certain amount of days), and then a user could just use bulk edit to close all those issues. So anybody with correct permissions could do "cleanup" whenever they wanted to, giving them more control.
I think this makes sense too, but I don't think this would meet the "automation" criteria of this issue.
First of all, thank you for raising an issue to help improve the GitLab product. This issue was labelled as a ~"feature proposal" in the past. In order to maintain order in the issue tracker, we are starting to close off old, unpopular feature proposals that have not gained many votes since opening.
This issue will be marked for closure, as it meets the following criteria:
Created over 1 year ago
Labelled as a ~"feature proposal"
Unscheduled (not associated with a milestone)
Less than 10 upvotes
Thanks for your help and please raise any new feature proposals as a new issue.
Ya, so if you could map the event in GitLab issues for an issue creation to a pipeline (or maybe a specific job in a pipeline, or a serverless handler) then you could write that job/pipeline/function to evaluate the issue, for example, and know that if it has the label ~"devops:release" plus ~feature that it gets assigned to @jlenny for initial triage. Whatever rules you might like could be implemented there.
Assuming the event contains the pointer to the object that triggered it, the pipeline/job/function could do all kinds of interesting things. I don't know if this is a good idea, but as an example you could make it so when a pipeline fails in an MR, the handler goes back to the MR, sees what issue it closes, and annotates that issue with the pipeline result. Maybe this gets spammy, I'm not sure, but you can see the possibilities.
@jlenny - Thanks, super clear. So all that logic lands in your gitlab-ci.yml file for the project? It seems like we are using the pipelines as generic automation engines (GitHub Actions?). Do we do that in other contexts already?
Well, this is a proposal so none of this exists yet. :) But yeah, my take is you'd put this in a "actions" project with a .gitlab-ci.yml defining the jobs.. the repo itself could have whatever code or configuration needed in order to do what it needs to do so the logic needn't go into the .gitlab-ci.yml itself, it could call out to programs in its repo.
A lovable implementation of this could include an awesome workflow builder UI with each action taken in GitLab easily mapped to dependencies on other actions. Of course custom actions could be defined in .gitlab-ci.yml and also visualized.
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. The current
gitlab-ce repository will become a read-only mirror, without any
proprietary code. All development is moved to the current
gitlab-ee repository, which we will rename to just gitlab in the
coming weeks. As part of this migration, issues will be moved to the
current gitlab-ee project.
If you have any questions about all of this, please ask them in our
dedicated FAQ issue.
You can also find more information here:
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to
rename gitlab-ce to gitlab-foss to make the purpose of this FOSS
repository more clear
I created a merge requests for CE, and this got closed. What do I
need to do?
Everything in the ee/ directory is proprietary. Everything else is
free and open source software. If your merge request does not change
anything in the ee/ directory, the process of contributing changes
is the same as when using the gitlab-ce repository.
Will you accept merge requests on the gitlab-ce/gitlab-foss project
after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in
gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git
remotes to use this new URL. GitLab will take care of redirecting Git
operations so there is no hard deadline, but we recommend doing this
as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?