There's some stuff we wouldn't use, as a rule. Much of it can be turned off on a per-project basis, but is there a global way to disable something like issues?
Mention has been made of project templates as a way to handle this - worth checking that out as well.
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| configure-projects: add an issue allowlist and tidy log output | repos/releng/gitlab-settings!10 | brennen | work/brennen/allowlist | main |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | None | T264231 Investigate whether issues, operations, wikis, etc. can be disabled globally on GitLab | |||
| Open | brennen | T355097 Add a timer to run gitlab-settings/configure-projects |
In my understanding it's currently not possible (but the upstream tickets confuse me a bit):
Change 699812 had a related patch set uploaded (by Brennen Bearnes; author: Brennen Bearnes):
[operations/gitlab-ansible@master] disable issues & wikis by default on new projects
Change 699812 merged by Brennen Bearnes:
[operations/gitlab-ansible@master] disable issues & wikis by default on new projects
Mentioned in SAL (#wikimedia-operations) [2021-06-22T19:58:32Z] <brennen> gitlab1001: run ansible to deploy https://gerrit.wikimedia.org/r/c/operations/gitlab-ansible/+/699812 (T264231)
See Draft: Add tools for configuring all projects. Needs a bit of work, but presumably we can run configure-projects as a periodic job.
The UI surprises me - Issues are listed in the sidebar, and https://gitlab.wikimedia.org/groups/releng/-/issues can be reached, but (rightfully) no project can be chosen (and https://gitlab.wikimedia.org/groups/releng/-/issues/new is a 404). The sidebar distraction might be something to forward to upstream?
The sidebar distraction might be something to forward to upstream?
There's a claim on the upstream Disable Issues at instance level (#213361):
We will eventually address this via the framework being developed for cascading settings -- #291082 (closed)
Following what happened after that gets a bit difficult, but it seems like some work has been done. Noting this to follow up on:
Cascading Namespace Settings developer documentation (#326524)
This ticket mostly discusses the technical implementation; have we decided as a policy matter that e.g. GitLab issues should not be used?
This ticket mostly discusses the technical implementation; have we decided as a policy matter that e.g. GitLab issues should not be used?
Broadly, yes, but see T304614: GitLab Issues experiment with Research for the current exception to that policy that I'm aware of.
That task had a later comment pointing to #2538 - Way to disable Issues globally and for good.:
A first comment proposed to implement it as a trigger in the database:
thinking about it, maybe a safer way is to create a trigger in postgres, attached to the insert and update events of the configuration that automatically sets that setting to false no matter what its value is. That may be the safer way to do it, unless adding a new trigger would screw up the updater.
But that sounds hacky!
Another comment hint at disabling the feature:
You can disable the Issues feature for new projects in the GitLab configuration file.
For an omnibus installation you'll be looking at the following value in /etc/gitlab/gitlab.rb file:/etc/gitlab/gitlab.rbgitlab_rails['gitlab_default_projects_features_issues'] = falseFor source in config/gitlab.yml:
config/gitlab.yml## Default project features settings default_projects_features: issues: false
The issue was left open pending update of the documentation. Maybe that is still available as a feature flag, at least their helm chart documentation refers to it. At https://docs.gitlab.com/charts/charts/globals.html#defaultprojectsfeatures :
defaultProjectsFeatures
Flags to decide if new projects should be created with the respective features by default. All > flags default to true.
defaultProjectsFeatures: issues: true mergeRequests: true wiki: true snippets: true builds: true containerRegistry: true
Change 954063 had a related patch set uploaded (by Hashar; author: Hashar):
[operations/puppet@production] gitlab: add project_features parameter to profile
Change 954064 had a related patch set uploaded (by Hashar; author: Hashar):
[operations/puppet@production] gitlab: disable issue tracker by default on devtools
Change 954065 had a related patch set uploaded (by Hashar; author: Hashar):
[operations/puppet@production] gitlab: disable issue tracker by default on production
Change 954072 had a related patch set uploaded (by Hashar; author: Hashar):
[operations/puppet@production] gitlab: project_features > default_projects_features
Change 954065 abandoned by Hashar:
[operations/puppet@production] gitlab: disable issue tracker by default on production
Reason:
Change 954064 abandoned by Hashar:
[operations/puppet@production] gitlab: disable issue tracker by default on devtools
Reason:
Without the cherry picks I have checked on `gitlab-prod-1002.devtools.eqiad1.wikimedia.cloud` and /etc/gitlab/gitlab.rb has:
gitlab_rails['gitlab_default_projects_features_issues'] = false
So I guess issue tracker is disabled by default but it can be reenabled in the interface. Anyway this change is useless :)
I have checked on gitlab-prod-1002.devtools.eqiad1.wikimedia.cloud and we have:
gitlab_rails['gitlab_default_projects_features_issues'] = false gitlab_rails['gitlab_default_projects_features_wiki'] = false gitlab_rails['gitlab_default_projects_features_snippets'] = false
So the issue tracker should be disabled on project by default, but I guess there is nothing preventing someone to reenable it?
Another thing I found is the Project API Create Project which has a parameter:
| Attribute | issues_access_level |
| Type | string |
| Required | No |
| Description | Enable issues for this project. One of disabled, private, or enabled |
I have no idea how it relates to the global gitlab_default_projects_features_issues though. One would have to dig into the source code.
Change 954072 merged by EoghanGaffney:
[operations/puppet@production] gitlab: project_features > default_projects_features
Change 954063 merged by Jelto:
[operations/puppet@production] gitlab: add default_project_features parameter to profile
I was going to move my repos for Wikimedia-related things from GitHub to gitlab.wikimedia.org, but disabling issues has made it completely unsuitable for me (and community repos in general, I guess, given how many people use sites like GitHub for issue tracking).
How can we access issues which were already created?
@Nikki: no one should have been using gitlab issues, projects can request a Phabricator task and track issues here.
To reframe how the last comment was written,
@Nikki, Could you explain your comment about being "completely unsuitable"? For example, Phabricator is available which is more feature rich (At least from my (very limited) understanding of GitHub issues).