Stop CI jobs

.gitlab/issue_templates/Bug.md

-<!---
-Please read this!
-
-Before opening a new issue, make sure to search for keywords in the issues
-filtered by the "regression" or "bug" label.
-
-For the Community Edition issue tracker:
-
-- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=regression
-- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=bug
-
-For the Enterprise Edition issue tracker:
-
-- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=regression
-- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=bug
-
-and verify the issue you're about to submit isn't a duplicate.
---->
-
-### Summary
-
-(Summarize the bug encountered concisely)
-
-### Steps to reproduce
-
-(How one can reproduce the issue - this is very important)
-
-### Example Project
-
-(If possible, please create an example project here on GitLab.com that exhibits the problematic behaviour, and link to it here in the bug report)
-
-(If you are using an older version of GitLab, this will also determine whether the bug has been fixed in a more recent version)
-
-### What is the current *bug* behavior?
-
-(What actually happens)
-
-### What is the expected *correct* behavior?
-
-(What you should see instead)
-
-### Relevant logs and/or screenshots
-
-(Paste any relevant logs - please use code blocks (```) to format console output,
-logs, and code as it's very hard to read otherwise.)
-
-### Output of checks
-
-(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)
-
-#### Results of GitLab environment info
-
-<details>
-<summary>Expand for output related to GitLab environment info</summary>
-<pre>
-
-(For installations with omnibus-gitlab package run and paste the output of:
-`sudo gitlab-rake gitlab:env:info`)
-
-(For installations from source run and paste the output of:
-`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
-
-</pre>
-</details>
-
-#### Results of GitLab application Check
-
-<details>
-<summary>Expand for output related to the GitLab application check</summary>
-<pre>
-
-(For installations with omnibus-gitlab package run and paste the output of:
-`sudo gitlab-rake gitlab:check SANITIZE=true`)
-
-(For installations from source run and paste the output of:
-`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`)
-
-(we will only investigate if the tests are passing)
-
-</pre>
-</details>
-
-### Possible fixes
-
-(If you can, link to the line of code that might be responsible for the problem)
-
-/label ~bug

.gitlab/issue_templates/Feature Proposal.md

-### Description
-
-(Include problem, use cases, benefits, and/or goals)
-
-### Proposal
-
-### Links / references
-
-/label ~"feature proposal"

.gitlab/issue_templates/Research Proposal.md

-### Background:
-
-(Include problem, use cases, benefits, and/or goals)
-
-**What questions are you trying to answer?**
-
-**Are you looking to verify an existing hypothesis or uncover new issues you should be exploring?**
-
-**What is the backstory of this project and how does it impact the approach?**
-
-**What do you already know about the areas you are exploring?**
-
-**What does success look like at the end of the project?**
-
-### Links / references:
-
-/label ~"UX research"

.gitlab/issue_templates/Security Developer Workflow.md

-<!--
-# Read me first!
-
-Create this issue under https://dev.gitlab.org/gitlab/gitlabhq
-
-Set the title to: `[Security] Description of the original issue`
--->
-
-### Prior to the security release
-
-- [ ] Read the [security process for developers] if you are not familiar with it.
-- [ ] Link to the original issue adding it to the [links section](#links)
-- [ ] Run `scripts/security-harness` in the CE, EE, and/or Omnibus to prevent pushing to any remote besides `dev.gitlab.org`
-- [ ] Create an MR targetting `org` `master`, prefixing your branch with `security-`
-- [ ] Label your MR with the ~security label, prefix the title with `WIP: [master]`   
-- [ ] Add a link to the MR to the [links section](#links)
-- [ ] Add a link to an EE MR if required
-- [ ] Make sure the MR remains in-progress and gets approved after the review cycle, **but never merged**.
-- [ ] Assign the MR to a RM once is reviewed and ready to be merged. Check the [RM list] to see who to ping.
-
-#### Backports
-
-- [ ] Once the MR is ready to be merged, create MRs targetting the last 3 releases
-    - [ ] At this point, it might be easy to squash the commits from the MR into one
-    - You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [seckpick documentation]
-    - [ ] Create the branch `security-X-Y` from `X-Y-stable` if it doesn't exist (and make sure it's up to date with stable)
-    - [ ] Create each MR targetting the security branch `security-X-Y`
-    - [ ] Add the ~security label and prefix with the version `WIP: [X.Y]` the title of the MR
-- [ ] Make sure all MRs have a link in the [links section](#links) and are assigned to a Release Manager.
-
-[seckpick documentation]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#secpick-script
-
-#### Documentation and final details
-
-- [ ] Check the topic on #security to see when the next release is going to happen and add a link to the [links section](#links)
-- [ ] Find out the versions affected (the Git history of the files affected may help you with this) and add them to the [details section](#details)
-- [ ] Fill in any upgrade notes that users may need to take into account in the [details section](#details)
-- [ ] Add Yes/No and further details if needed to the migration and settings columns in the [details section](#details)
-- [ ] Add the nickname of the external user who found the issue (and/or HackerOne profile) to the Thanks row in the [details section](#details)
-
-### Summary
-#### Links
-
-| Description | Link |
-| -------- | -------- |
-| Original issue   | #TODO  |
-| Security release issue   | #TODO  |
-| `master` MR | !TODO   |
-| `master` MR (EE) | !TODO   |
-| `Backport X.Y` MR | !TODO   |
-| `Backport X.Y` MR | !TODO   |
-| `Backport X.Y` MR | !TODO   |
-| `Backport X.Y` MR (EE) | !TODO   |
-| `Backport X.Y` MR (EE) | !TODO   |
-| `Backport X.Y` MR (EE) | !TODO   |
-
-#### Details
-
-| Description | Details | Further details|
-| -------- | -------- | -------- |
-| Versions affected | X.Y  | |
-| Upgrade notes | | |
-| GitLab Settings updated | Yes/No| |
-| Migration required | Yes/No | |
-| Thanks | | |
-
-[security process for developers]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
-[RM list]:  https://about.gitlab.com/release-managers/
-
-/label ~security 

.gitlab/merge_request_templates/Database Changes.md

-Add a description of your merge request here. Merge requests without an adequate
-description will not be reviewed until one is added.
-
-## Database Checklist
-
-When adding migrations:
-
-- [ ] Updated `db/schema.rb`
-- [ ] Added a `down` method so the migration can be reverted
-- [ ] Added the output of the migration(s) to the MR body
-- [ ] Added tests for the migration in `spec/migrations` if necessary (e.g. when migrating data)
-
-When adding or modifying queries to improve performance:
-
-- [ ] Included data that shows the performance improvement, preferably in the form of a benchmark
-- [ ] Included the output of `EXPLAIN (ANALYZE, BUFFERS)` of the relevant queries
-
-When adding foreign keys to existing tables:
-
-- [ ] Included a migration to remove orphaned rows in the source table before adding the foreign key
-- [ ] Removed any instances of `dependent: ...` that may no longer be necessary
-
-When adding tables:
-
-- [ ] Ordered columns based on the [Ordering Table Columns](https://docs.gitlab.com/ee/development/ordering_table_columns.html#ordering-table-columns) guidelines
-- [ ] Added foreign keys to any columns pointing to data in other tables
-- [ ] Added indexes for fields that are used in statements such as WHERE, ORDER BY, GROUP BY, and JOINs
-
-When removing columns, tables, indexes or other structures:
-
-- [ ] Removed these in a post-deployment migration
-- [ ] Made sure the application no longer uses (or ignores) these structures
-
-## General Checklist
-
-- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) added, if necessary
-- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/doc_styleguide.html)
-- [ ] API support added
-- [ ] Tests added for this feature/bug
-- Conform by the [code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
-  - [ ] Has been reviewed by a Backend maintainer
-  - [ ] Has been reviewed by a Database specialist
-- [ ] Conform by the [merge request performance guides](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
-- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/CONTRIBUTING.md#style-guides)
-- [ ] If you have multiple commits, please combine them into a few logically organized commits by [squashing them](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
-- [ ] Internationalization required/considered
-- [ ] If paid feature, have we considered GitLab.com plan and how it works for groups and is there a design for promoting it to users who aren't on the correct plan
-- [ ] End-to-end tests pass (`package-and-qa` manual pipeline job)
-
-/label ~database

.gitlab/merge_request_templates/Documentation.md

-<!--See the general Documentation guidelines https://docs.gitlab.com/ce/development/writing_documentation.html -->
-
-## What does this MR do?
-
-<!-- Briefly describe what this MR is about -->
-
-## Related issues
-
-<!-- Mention the issue(s) this MR closes or is related to -->
-
-Closes 
-
-## Moving docs to a new location?
-
-Read the guidelines:
-https://docs.gitlab.com/ce/development/writing_documentation.html#changing-document-location
-
-- [ ] Make sure the old link is not removed and has its contents replaced with
-      a link to the new location.
-- [ ] Make sure internal links pointing to the document in question are not broken.
-- [ ] Search and replace any links referring to old docs in GitLab Rails app,
-      specifically under the `app/views/` and `ee/app/views` (for GitLab EE)  directories.
-- [ ] Make sure to add [`redirect_from`](https://docs.gitlab.com/ce/development/writing_documentation.html#redirections-for-pages-with-disqus-comments)
-      to the new document if there are any Disqus comments on the old document thread.
-- [ ] If working on CE and the `ee-compat-check` jobs fails, submit an MR to EE
-      with the changes as well (https://docs.gitlab.com/ce/development/writing_documentation.html#cherry-picking-from-ce-to-ee).
-- [ ] Ping one of the technical writers for review.
-
-/label ~Documentation

.gitlab/route-map.yml

-# Documentation
-- source: /doc/(.+?)\.md/ # doc/administration/build_artifacts.md
-  public: '\1.html' # doc/administration/build_artifacts.html