GitLab Triage issueshttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues2023-08-28T14:03:46Zhttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/215Add branches as resource_rules2023-08-28T14:03:46ZLukas ZeitlerAdd branches as resource_rulesIt would be quite useful if you could also sort out `branches` besides issues and merge requests. For example, you could also monitor branches and automatically delete them after a certain period of inactivity or if it is too many commit...It would be quite useful if you could also sort out `branches` besides issues and merge requests. For example, you could also monitor branches and automatically delete them after a certain period of inactivity or if it is too many commits behind.
Maybe it's already possible to do so, but I couldn't figure it out reading the documentation.Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/206Add condition to check if merge-request was opened for issue2024-02-24T15:29:38ZLukas Mertensgit@lukas-mertens.deAdd condition to check if merge-request was opened for issueIt would be nice if you were able to filter issues for which at least one merge request was opened. For our workflow we want to attach a label "testing" to these Issues.It would be nice if you were able to filter issues for which at least one merge request was opened. For our workflow we want to attach a label "testing" to these Issues.Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/201Filter by author of most recent update2023-08-15T07:25:49ZJulian StirlingFilter by author of most recent updateIt would be good to have a way to filter issues by the author of the most recent update (not the author of the issue).
#### Our use case
The Gathering for Open Science Hardware use a GitLab issue tracker for the long term community roa...It would be good to have a way to filter issues by the author of the most recent update (not the author of the issue).
#### Our use case
The Gathering for Open Science Hardware use a GitLab issue tracker for the long term community roadmap. We like members to update us occasionally on progress (or lack thereof). We has started using triage to ask people for updates if the issue has not been updated in the last 3 months. This works well.
#### What we want to do
A large part of our community is not on GitLab. We would like to have a summary of recent updates, we will pool these into a summary issue, which can then be transferred to our forum. The summery would include:
* Issues updated in the last 2 weeks
* Number of stale issues
#### The problem
The problem here is that if our BOT has commented on the issue then it has been updated. If we could filter out updates from the bot when collecting issues we could have a more accurate picture of the community engagement.Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/187Add action to configure settings for issues/merge_requests2023-10-04T09:05:18ZBhushan ShahAdd action to configure settings for issues/merge_requestsWe at KDE are planning to use gitlab-triage for some operations, one thing which we are missing in gitlab is, gitlab-org/gitlab#25889
so I was wondering if gitlab-triage bot can be re-used to set that configuration on the merge requests...We at KDE are planning to use gitlab-triage for some operations, one thing which we are missing in gitlab is, gitlab-org/gitlab#25889
so I was wondering if gitlab-triage bot can be re-used to set that configuration on the merge requests?
Example policy being
```
resource_rules:
merge_requests:
rules:
- name: My policy
conditions:
date:
attribute: updated_at
condition: older_than
interval_type: days
interval: 7
state: opened
actions:
configure:
allow_configuration: true
```
I am trying to understand the code-base and was wondering best way to add this code? Help welcome :smile:Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/178Linting for policy files2023-07-31T20:38:03ZMark FletcherLinting for policy filesIt's quite easy to create a valid yml policy but put the fields in the wrong place. Maybe wrong indentation or incorrect spelling. I wonder if we could run some checks for expected fields and those that look out of place
References:
- #177It's quite easy to create a valid yml policy but put the fields in the wrong place. Maybe wrong indentation or incorrect spelling. I wonder if we could run some checks for expected fields and those that look out of place
References:
- #177Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/157Condition to filter upon checklist status for Issue and/or Merge Request2023-09-06T13:00:28ZMark FletcherCondition to filter upon checklist status for Issue and/or Merge Request#### Summary
Allow filtering upon the checklist status of an issue or a merge request
#### Proposal
It's possible to determine the checklist status of an issue or merge request via the API:
- https://docs.gitlab.com/ce/api/issues.html...#### Summary
Allow filtering upon the checklist status of an issue or a merge request
#### Proposal
It's possible to determine the checklist status of an issue or merge request via the API:
- https://docs.gitlab.com/ce/api/issues.html#single-issue
- https://docs.gitlab.com/ce/api/merge_requests.html#single-issue
Via the `task_completion_status` field
#### Use cases
- Close the open triage package issues where all items have been checked off as completed
- Find triage package issues with outstanding task list itemshttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/152Ignore issues/MRs when the project is archived2020-09-17T10:05:05ZRémy CoutableIgnore issues/MRs when the project is archivedIn https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/213, we performed a mass-migration of team labels to stage/group labels for the whole https://gitlab.com/gitlab-org group.
In doing that, some issues (e.g. https://gitla...In https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/213, we performed a mass-migration of team labels to stage/group labels for the whole https://gitlab.com/gitlab-org group.
In doing that, some issues (e.g. https://gitlab.com/gitlab-org/gitlab-ci-yml/issues/83) weren't updated because their project is archived (e.g. https://gitlab.com/gitlab-org/gitlab-ci-yml). The issue itself isn't locked according to the API:
```json
{
"id": 14415577,
"iid": 83,
"project_id": 1209837,
"title": "--version flag - Auto-DevOps.gitlab-ci.yml",
"description": "https://gitlab.com/gitlab-org/gitlab-ci-yml/blame/master/Auto-DevOps.gitlab-ci.yml#L608\n\nAny idea why `--version` flag is used here ? @nolith @mayra\\-cabrera @DylanGriffith ?\n\nThe auto-deploy-app chart wouldn't have this version `\"$CI_PIPELINE_ID-$CI_JOB_ID\"`\n\n```\nhelm help upgrade\n\nFlags:\n--version string specify the exact chart version to use. If this is not specified, the latest version is used\n```",
"state": "closed",
"created_at": "2018-09-24T04:39:38.341Z",
"updated_at": "2018-09-24T11:48:01.716Z",
"closed_at": "2018-09-24T11:22:16.116Z",
"closed_by": {
"id": 120073,
"name": "Dylan Griffith",
"username": "DylanGriffith",
"state": "active",
"avatar_url": "https://assets.gitlab-static.net/uploads/-/system/user/avatar/120073/avatar.png",
"web_url": "https://gitlab.com/DylanGriffith"
},
"labels": [
"Configure",
"auto devops"
],
"milestone": {
"id": 567670,
"iid": 19,
"group_id": 9970,
"title": "11.4",
"description": "",
"state": "closed",
"created_at": "2018-06-14T17:31:41.249Z",
"updated_at": "2018-12-20T06:49:55.749Z",
"due_date": "2018-10-22",
"start_date": "2018-09-08",
"web_url": "https://gitlab.com/groups/gitlab-org/-/milestones/19"
},
"assignees": [
{
"id": 2535118,
"name": "Thong Kuah",
"username": "tkuah",
"state": "active",
"avatar_url": "https://secure.gravatar.com/avatar/f7b51bdd49a4914d29504d7ff4c3f7b9?s=80&d=identicon",
"web_url": "https://gitlab.com/tkuah"
}
],
"author": {
"id": 2535118,
"name": "Thong Kuah",
"username": "tkuah",
"state": "active",
"avatar_url": "https://secure.gravatar.com/avatar/f7b51bdd49a4914d29504d7ff4c3f7b9?s=80&d=identicon",
"web_url": "https://gitlab.com/tkuah"
},
"assignee": {
"id": 2535118,
"name": "Thong Kuah",
"username": "tkuah",
"state": "active",
"avatar_url": "https://secure.gravatar.com/avatar/f7b51bdd49a4914d29504d7ff4c3f7b9?s=80&d=identicon",
"web_url": "https://gitlab.com/tkuah"
},
"user_notes_count": 6,
"merge_requests_count": 1,
"upvotes": 0,
"downvotes": 0,
"due_date": null,
"confidential": false,
"discussion_locked": null,
"web_url": "https://gitlab.com/gitlab-org/gitlab-ci-yml/issues/83",
"time_stats": {
"time_estimate": 0,
"total_time_spent": 0,
"human_time_estimate": null,
"human_total_time_spent": null
},
"task_completion_status": {
"count": 0,
"completed_count": 0
},
"has_tasks": false,
"_links": {
"self": "https://gitlab.com/api/v4/projects/1209837/issues/83",
"notes": "https://gitlab.com/api/v4/projects/1209837/issues/83/notes",
"award_emoji": "https://gitlab.com/api/v4/projects/1209837/issues/83/award_emoji",
"project": "https://gitlab.com/api/v4/projects/1209837"
},
"subscribed": false,
"weight": null
}
```
but the project is archived:
```json
{
"id": 1209837,
"description": "This project has been deprecated and the templates have been moved to https://gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/gitlab/ci/templates",
"name": "GitLab CI Yml - Deprecated",
"name_with_namespace": "GitLab.org / GitLab CI Yml - Deprecated",
"path": "gitlab-ci-yml",
"path_with_namespace": "gitlab-org/gitlab-ci-yml",
"created_at": "2016-05-20T21:02:35.623Z",
"default_branch": "master",
"tag_list": [],
"ssh_url_to_repo": "git@gitlab.com:gitlab-org/gitlab-ci-yml.git",
"http_url_to_repo": "https://gitlab.com/gitlab-org/gitlab-ci-yml.git",
"web_url": "https://gitlab.com/gitlab-org/gitlab-ci-yml",
"readme_url": "https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/README.md",
"avatar_url": "https://gitlab.com/gitlab-org/gitlab-ci-yml/-/avatar",
"star_count": 422,
"forks_count": 142,
"last_activity_at": "2019-04-12T13:35:14.415Z",
"namespace": {
"id": 9970,
"name": "GitLab.org",
"path": "gitlab-org",
"kind": "group",
"full_path": "gitlab-org",
"parent_id": null,
"avatar_url": "/uploads/-/system/group/avatar/9970/logo-extra-whitespace.png",
"web_url": "https://gitlab.com/groups/gitlab-org"
},
"_links": {
"self": "https://gitlab.com/api/v4/projects/1209837",
"issues": "https://gitlab.com/api/v4/projects/1209837/issues",
"merge_requests": "https://gitlab.com/api/v4/projects/1209837/merge_requests",
"repo_branches": "https://gitlab.com/api/v4/projects/1209837/repository/branches",
"labels": "https://gitlab.com/api/v4/projects/1209837/labels",
"events": "https://gitlab.com/api/v4/projects/1209837/events",
"members": "https://gitlab.com/api/v4/projects/1209837/members"
},
"empty_repo": false,
"archived": true,
"visibility": "public",
"resolve_outdated_diff_discussions": null,
"container_registry_enabled": false,
"issues_enabled": true,
"merge_requests_enabled": true,
"wiki_enabled": false,
"jobs_enabled": true,
"snippets_enabled": false,
"issues_access_level": "enabled",
"repository_access_level": "enabled",
"merge_requests_access_level": "enabled",
"wiki_access_level": "disabled",
"builds_access_level": "enabled",
"snippets_access_level": "disabled",
"shared_runners_enabled": true,
"lfs_enabled": true,
"creator_id": 87854,
"import_status": "none",
"import_error": null,
"open_issues_count": 24,
"runners_token": "94fjny8tfudP7no8F8i-",
"ci_default_git_depth": null,
"public_jobs": true,
"build_git_strategy": "fetch",
"build_timeout": 3600,
"auto_cancel_pending_pipelines": "enabled",
"build_coverage_regex": "Coverage:\\s(\\d+)",
"ci_config_path": "",
"shared_with_groups": [],
"only_allow_merge_if_pipeline_succeeds": false,
"request_access_enabled": false,
"only_allow_merge_if_all_discussions_are_resolved": false,
"printing_merge_request_link_enabled": true,
"merge_method": "merge",
"auto_devops_enabled": false,
"auto_devops_deploy_strategy": "continuous",
"permissions": {
"project_access": null,
"group_access": null
},
"repository_storage": "nfs-file04",
"approvals_before_merge": 0,
"mirror": false,
"external_authorization_classification_label": "",
"packages_enabled": null
}
```
`gitlab-triage` should probably ignore those resources when their project is archived.https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/150Fetch the API using threads2019-11-06T07:31:16ZRémy CoutableFetch the API using threadsSince fetching the API is I/O only, we can leverage threads.
Ideally we'd have a thread pool and each thread would fetch a different page.Since fetching the API is I/O only, we can leverage threads.
Ideally we'd have a thread pool and each thread would fetch a different page.https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/149Allow a directory of triage policies as a command line parameter2022-09-02T08:08:17ZMark FletcherAllow a directory of triage policies as a command line parameter- We may want a command to load a full directory of organised policies for execution
- Create a command line option to declare the directory path and the intention to use a full directory of policies
Example:
- Group triage package pol...- We may want a command to load a full directory of organised policies for execution
- Create a command line option to declare the directory path and the intention to use a full directory of policies
Example:
- Group triage package policies could be housed in their own directory policies/group_packages/group_*_package.ymlhttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/145Cache the context for Ruby condition and comment action2022-02-24T09:29:13ZLin Jen-ShinCache the context for Ruby condition and comment actionIn `lib/gitlab/triage/filters/ruby_conditions_filter.rb` and `lib/gitlab/triage/command_builders/text_content_builder.rb` we're creating two context objects but they can actually be shared, so that we can cache `labels_chronologically` a...In `lib/gitlab/triage/filters/ruby_conditions_filter.rb` and `lib/gitlab/triage/command_builders/text_content_builder.rb` we're creating two context objects but they can actually be shared, so that we can cache `labels_chronologically` and avoid making the same API request twice.Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/136Split triage package items across multiple assignees2019-11-06T07:31:53ZMark FletcherSplit triage package items across multiple assigneesA triage package can contain many issues, we are seeing an emerging requirement to be able to distribute the workload in a triage package across multiple users.
Could we:
1. Take all items
2. Take all potential assignees
3. Split the wo...A triage package can contain many issues, we are seeing an emerging requirement to be able to distribute the workload in a triage package across multiple users.
Could we:
1. Take all items
2. Take all potential assignees
3. Split the workload equally
4. Create a list for each assigneehttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/135Introduce Milestone#first_started_with2020-10-30T18:22:40ZLin Jen-ShinIntroduce Milestone#first_started_withFollow up from https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/123#note_162516230
We can define this so that we don't need to repeat this in triage-ops:
``` ruby
class Milestone
def first_started_with(regexp = //) # d...Follow up from https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/123#note_162516230
We can define this so that we don't need to repeat this in triage-ops:
``` ruby
class Milestone
def first_started_with(regexp = //) # default matches everything
today = Date.today
all_started
.select { |milestone| milestone.title.match?(regexp) }
.reverse_each.find { |milestone| milestone.start_date < today }
end
end
```
This might be generic enough.
However, we might also take https://gitlab.com/gitlab-org/gitlab-triage/issues/121 into account, where we try to make `Milestone#succ` more flexible. Basically, we also want to stop this workaround: https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/81Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/134Introduce comment_with_ruby and comment_with_ruby_file2020-10-30T18:22:40ZLin Jen-ShinIntroduce comment_with_ruby and comment_with_ruby_fileIn https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/122 we're apparently abusing Ruby inside the `comment` action, which the whole comment is under Ruby scripts and no plain text at all.
If we need to use it that way, it ...In https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/122 we're apparently abusing Ruby inside the `comment` action, which the whole comment is under Ruby scripts and no plain text at all.
If we need to use it that way, it means we do want to have full Ruby support. So we can add `comment_with_ruby` and `comment_with_ruby_file`:
``` yaml
action:
comment_with_ruby: |
conditions = YAML.load_file('policies/add-stage-labels.yml')
.dig('resource_rules', 'issues', 'rules', 0, 'conditions')
.with_indifferent_access
all_labels = ExpandCondition::List.expand(conditions)
.flat_map { |condition| condition['labels'] }
.slice_before(/^section#/)
.group_by(&:first)
manage_control = all_labels.dig('section#manage_control' , 0)[1..-1]
if (resource[:labels] & manage_control).any?
puts '/label ~Manage ~"group:control" ~"devops:manage"'
end
comment_with_ruby_file: awesome.rb
```
So it can run in the context of a `StringIO` like object, and we treat the `StringIO#string` in the end as the comment. This way we can avoid noises and use pure Ruby.Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/131Move data processing out of engine to the corresponding policy2019-11-06T07:32:05ZLin Jen-ShinMove data processing out of engine to the corresponding policyWe should move data processing out of engine, and put them in the corresponding policy file. Specifically `summary_parts_for_rules` and `resources_for_rule`.
The following discussion from !93 should be addressed:
- [ ] @godfat started ...We should move data processing out of engine, and put them in the corresponding policy file. Specifically `summary_parts_for_rules` and `resources_for_rule`.
The following discussion from !93 should be addressed:
- [ ] @godfat started a [discussion](https://gitlab.com/gitlab-org/gitlab-triage/merge_requests/93#note_150930953):
> We might want to extract this to somewhere out of the engine! Maybe in the policy class.Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/129Allow manipulation of linked issues2022-03-14T12:24:00ZBertrand JaminAllow manipulation of linked issuesIs the a way to manipulate linked issues in conditions or actions ?
If no I think that it could be really useful.
My usecase is to have some "Scope issues" which contains multiple children issues and be sure that all issues of my pro...Is the a way to manipulate linked issues in conditions or actions ?
If no I think that it could be really useful.
My usecase is to have some "Scope issues" which contains multiple children issues and be sure that all issues of my project are linked to at least one "Scope issue"
Thanks for your help.https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/127Validate --source is a valid value2021-05-22T19:07:15ZLin Jen-ShinValidate --source is a valid valueSo we can have a easier to understand error message than: https://gitlab.com/gitlab-org/quality/triage-ops/issues/131So we can have a easier to understand error message than: https://gitlab.com/gitlab-org/quality/triage-ops/issues/131Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/123Enable filtering on `closed_at` in Date condition2022-07-28T21:44:58ZMark FletcherEnable filtering on `closed_at` in Date conditionFor example, it could be useful to find issues that were closed in the past weekFor example, it could be useful to find issues that were closed in the past weekBackloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/119Skip confidential resource by default2023-09-18T16:44:56ZLin Jen-ShinSkip confidential resource by defaultIn https://gitlab.com/gitlab-org/gitlab-triage/issues/98 we provide:
``` yaml
redact_confidential_resources: true # default
```
We should provide another default:
``` yaml
skip_confidential_resources: true # default
```
We'll need th...In https://gitlab.com/gitlab-org/gitlab-triage/issues/98 we provide:
``` yaml
redact_confidential_resources: true # default
```
We should provide another default:
``` yaml
skip_confidential_resources: true # default
```
We'll need this for https://gitlab.com/gitlab-org/quality/triage-ops/issues/75Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/118Regular actions for the rules under summaries2021-04-20T15:42:01ZLin Jen-ShinRegular actions for the rules under summariesIn https://gitlab.com/gitlab-org/gitlab-triage/issues/112 we implemented a way to have a summary from other summaries.
However only the `summarize` action in `summaries` will actually act, all other actions are not regular actions. For ...In https://gitlab.com/gitlab-org/gitlab-triage/issues/112 we implemented a way to have a summary from other summaries.
However only the `summarize` action in `summaries` will actually act, all other actions are not regular actions. For example, all the sub-summaries will not post their own summary, but being collected into the owner's summary. `comment` and other actions are also completely ignored.
We thought we could work around this shortcoming by duplicating the same rule and use regular actions, but in https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/58#note_121834020 we realized that this won't work well, because the meta-summary will refer to the issues we want to add comments, which will alter the `updated_at` attribute for the issue, which will affect the conditions we're filtering against!
This means we still need to finish the actions in one run, somehow making this a transaction (conceptually).
The only thing which I think might be inconsistent is that, the sub-summary won't act as a regular summary. But that's exactly why we want to have meta-summary, so I guess that's ok. All the other sub-actions could just act as regular actions.Backloghttps://gitlab.com/gitlab-org/ruby/gems/gitlab-triage/-/issues/117Tests against Gitlab::Triage::OptionParser2019-11-06T07:32:30ZLin Jen-ShinTests against Gitlab::Triage::OptionParserWe didn't have tests for things in `bin/gitlab-triage`. We did dry-run to test it out, but it's not using all the options.
~~We should move `TriageOptionParser` under `lib/*` and write actual tests against it. `bin/gitlab-triage` should...We didn't have tests for things in `bin/gitlab-triage`. We did dry-run to test it out, but it's not using all the options.
~~We should move `TriageOptionParser` under `lib/*` and write actual tests against it. `bin/gitlab-triage` should be minimal.~~Backlog