GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2020-08-14T11:06:29Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/33921Create Stronger Affordances for Forked Repos2020-08-14T11:06:29ZJuan J. RamirezCreate Stronger Affordances for Forked Repos### Problem to solve
Currently, the differences between a forked repo and the original repo are too subtle. This could lead to some confusion for the final user, especially if they are performing isolated work on the fork and other coll...### Problem to solve
Currently, the differences between a forked repo and the original repo are too subtle. This could lead to some confusion for the final user, especially if they are performing isolated work on the fork and other collaborative work on the original.
We should improve the affordances of forked repos, so it's more clear to the user they are currently on the fork and not the original.
![image](/uploads/f5b517640ee37392ddcd2b62ce90f5a4/image.png)
![image](/uploads/c0c03c265c4ecba6fa80851fd57e46e2/image.png)
### Intended users
* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
Increase the visibility of "forked from" or "fork" status of the repo, by adding stronger affordances. Some ideas:
- Include the namespace in the title of the repo
- Add some visual affordance that indicates this is a fork in the sidebar heading and the title of the main container.
- Move the "Forked from: line closer to the title. Also, show it on the sidebar heading.
- When merging or committing, also add some helper label or visual affordance in that view to indicate if the MR is going from a forked repo branch to another forked repo branch, or from a forked repo branch to an original repo branch.
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?-->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. -->
### Testing
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
### What is the type of buyer?
<!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
### Links / referenceshttps://gitlab.com/gitlab-org/gitlab/-/issues/13674Approval rules based on labels2023-01-17T05:22:27ZNathan Friendhello@nathanfriend.ioApproval rules based on labels### Proposal
Allow approvers to be determined by a merge request's labels.
For example, a merge request with ~UX, ~frontend, and ~database labels would require an approval from each of those groups.
### Further details
We already hav...### Proposal
Allow approvers to be determined by a merge request's labels.
For example, a merge request with ~UX, ~frontend, and ~database labels would require an approval from each of those groups.
### Further details
We already have the ability to set up approval rules based on the files that were changed in a merge request using [CODEOWNERS](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#code-owners-approvals-premium).
In some cases, determining approvals based on the files that were changed isn't enough. For example, at GitLab, every user-facing change needs to be reviewed by ~UX. However, it's not possible to determine whether or not a change is user-facing simply by looking at the files that were changed. A change to a Vue file might change the interface (which would require ~UX approval), or it might be internal refactor that has no effect on the interface (which would **not** require ~UX approval).
In the example above, it would be more accurate to determine the approvers based on labels. A merge request with the ~UX label should include a ~UX approver.
### Intended users
~"Persona: Software developer" ~"Persona: Product Designer"
### What does success look like, and how can we measure that?
We could use this feature internally to ensure that our merge requests always follow the appropriate approval process.https://gitlab.com/gitlab-org/gitlab/-/issues/30960Expand context in diffs is too noisy2020-08-14T11:11:24ZVasili ChyrvonExpand context in diffs is too noisyHi!
Want to grab your attention to the fact that new expand context UI (Show all lines) in diffs is too noisy.
It's colored, has bigger font size than codе, centered and sits on big bar.
This distracts from main task - reading the cod...Hi!
Want to grab your attention to the fact that new expand context UI (Show all lines) in diffs is too noisy.
It's colored, has bigger font size than codе, centered and sits on big bar.
This distracts from main task - reading the code.
Could you please fix it?
![Снимок_экрана_2019-08-15_в_17.49.31](/uploads/b68fdcbf3e0b8882c25b8efdf408e852/Снимок_экрана_2019-08-15_в_17.49.31.png)https://gitlab.com/gitlab-org/gitlab/-/issues/30951Multiple merge request targets2023-11-24T08:52:59ZBob Van Landuytbob@gitlab.comMultiple merge request targetsIn our workflow for gitlab-ce~2779335 issues, we currently create 4 (assuming single codebase) merge requests: 1 to `master`, and 3 to the latest `*-stable` branches.
The review process takes place on the merge request targeting master,...In our workflow for gitlab-ce~2779335 issues, we currently create 4 (assuming single codebase) merge requests: 1 to `master`, and 3 to the latest `*-stable` branches.
The review process takes place on the merge request targeting master, after the MR is approved the other merge requests are created and finally assigned to the bot that will merge all of the merge requests.
This can sometimes cause issues: https://gitlab.com/gitlab-org/release/framework/issues/442.
I think we could make this process easier if we only had to create one merge request and specify multiple branches it needs to be merged into:
The diffs being shown are the ones to the "main target branch": `master`
We show a widget showing the mergeability with the other target branches.
0. Conflicts or not: When there are conflicts, we'll need to create a separate merge request that we'll merge first, that way the target is fulfilled as there are no more changes.
0. Run a pipelines on the merge commit to see if there are spec failures.
The merge request is only mergeable if the merge can take place on all targets and GitLab takes care not to perform the merge if one of the the targets fails.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/13524Upload designs through modal with commit message2023-01-30T15:17:28ZJarek OstrowskiUpload designs through modal with commit message### Problem to solve
Uploading designs doesn't give you an opportunity to add a commit message. The current flow is:
1. Click "Add designs"
1. Select designs to upload
1. Click "Upload"
### Intended users
Users who add designs.
###...### Problem to solve
Uploading designs doesn't give you an opportunity to add a commit message. The current flow is:
1. Click "Add designs"
1. Select designs to upload
1. Click "Upload"
### Intended users
Users who add designs.
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
### Proposal
Add an upload modal (similar to the upload file modal) where you can add your designs and commit message. This modal potentially adds the ability to have thumbnail previews as well.
![Screenshot_2019-08-15_08.50.16](/uploads/346bc8813782db1060916133a80e4434/Screenshot_2019-08-15_08.50.16.png)
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### Testing
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
### What is the type of buyer?
<!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
### Links / references
cc @phikaiBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/30887Add indexes for the RemoteMirror.stuck query2023-12-22T00:10:51ZBob Van Landuytbob@gitlab.comAdd indexes for the RemoteMirror.stuck queryCurrently we're using this query to mark all these mirrors as failed.
The query is always scoped to a project, so they're never more than a handful of rows to update.
But Ideally we'd have an index for `project_id, last_update_started_...Currently we're using this query to mark all these mirrors as failed.
The query is always scoped to a project, so they're never more than a handful of rows to update.
But Ideally we'd have an index for `project_id, last_update_started_at, last_update_at` after https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31247 gets merged.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/30884Using WebIDE as issue-editor2020-08-14T11:11:33ZLong NguyenUsing WebIDE as issue-editor### Problem to solve
When edit issue in current issue editor, it has no syntax highlighting. So we could missed some markdown syntax.
### Intended users
<!-- Who will use this feature? If known, include any of the following: types of...### Problem to solve
When edit issue in current issue editor, it has no syntax highlighting. So we could missed some markdown syntax.
### Intended users
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
All user
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
Can we use WebIDE to edit issue? just treat an issue as an markdown file.
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
Using WebIDE as issue editor
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
Users who edit issue would benefit from markdown syntax highlighting right from issue editor.https://gitlab.com/gitlab-org/gitlab/-/issues/30844Repository Creation Process Should Take Email Addresses Into Account2023-02-09T12:17:36ZtmRepository Creation Process Should Take Email Addresses Into Account### Problem to solve
I have multiple emails associated with my account and want to create individual repos with not all the same email addresses for the initial commit, but have an option to choose which one to use if there are more tha...### Problem to solve
I have multiple emails associated with my account and want to create individual repos with not all the same email addresses for the initial commit, but have an option to choose which one to use if there are more than one.
### Intended users
At least every person creating a repository inside Gitlab, who also has multiple email addresses associated with their account, will probably use this. This might most likely be Developers, Project Managers or Team Leads.
### Further details
Currently, when I create a repository inside Gitlab, then I can not choose the email address for the initial commit. As a result, when I clone the repository and then commit further, there is one commit with the wrong email address. I know how to rectify that, but if I do, then I get merge conflicts later down the road due to "unrelated branches". This collides with the code review process - otherwise I could just push -f, but updating the email address for said commit results in all approvals to be anulled. Being able to choose an email address from the list of registered email addresses would solve this problem.
Please note that I am currently using a personal account on gitlab.com, but are registered as a developer for some projects of a paying customer (I develop for them). I also have an email from them, which I want to use on repos created for them.
### Proposal
You would change the repository creation process to conditionally include a field for the initial email address if the user has registered more than one email address to their account. Then you would configure the newly created repo to use that email address for the first commit.
Later on you can get fancy and have some elaborate management of emails and repo patterns to make the process smoother for people with many emails or many repositories.
### Permissions and Security
Nobody needs to have more permissions than they have already.
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
### Testing
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
### Links / referenceshttps://gitlab.com/gitlab-org/gitlab/-/issues/30836Link to issues and wikis with project ids instead of names2020-08-14T11:11:46ZCharuru CharuruLink to issues and wikis with project ids instead of names### Problem to solve
I want to be able to link into project's other pages than just the home page. /projects/4/issues currently does not work, but it should. I have an external application that integrates with gitlab that we use to help...### Problem to solve
I want to be able to link into project's other pages than just the home page. /projects/4/issues currently does not work, but it should. I have an external application that integrates with gitlab that we use to help with development, but there isn't a way to link to issues or wiki pages without using the brittle name based links.
### Intended users
Everyone who needs to be linked from an external application directly into gitlab.
### Further details
This can be worked around by saving the project namespace externally and then making a system webhook to update the name whenever it's changed, but it seems so much simpler to just have the projects/id user work. It's pretty inconsistent that the projects/id work but inner links do not.https://gitlab.com/gitlab-org/gitlab/-/issues/13427Remove designs when the issue is removed2023-01-30T15:18:03ZBob Van Landuytbob@gitlab.comRemove designs when the issue is removedWhen an issue is deleted, the deletion will cascade for the database records thanks to the foreign keys.
But we don't do anything to the files stored in the repository and in LFS, should we delete those in a new version or should we rew...When an issue is deleted, the deletion will cascade for the database records thanks to the foreign keys.
But we don't do anything to the files stored in the repository and in LFS, should we delete those in a new version or should we rewrite history to get rid of all the files?Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/30818Option to assign MR by default to author2023-04-17T17:16:39ZMartin DevillersOption to assign MR by default to authorThere are already a few issues linked to the assignment of MRs, but I haven't found one which suggests this (correct me if I'm wrong), which would be the simplest and most useful behavior for us.
It's a per-project option so that whene...There are already a few issues linked to the assignment of MRs, but I haven't found one which suggests this (correct me if I'm wrong), which would be the simplest and most useful behavior for us.
It's a per-project option so that whenever a MR is open the author is by default assigned to the MR.https://gitlab.com/gitlab-org/gitlab/-/issues/30789Add "Connection Status" and "Cluster Health" to Elasticsearch GitLab indices2023-06-08T14:48:21ZMarcel van Remmerdenmvanremmerden@gitlab.comAdd "Connection Status" and "Cluster Health" to Elasticsearch GitLab indicesIn a conversation around the Elasticsearch Admin UI, @mwasilewski-gitlab mentioned that it would be a huge improvement with minimal effort to also display the connection status and cluster health for each GitLab index.
A first mockup wo...In a conversation around the Elasticsearch Admin UI, @mwasilewski-gitlab mentioned that it would be a huge improvement with minimal effort to also display the connection status and cluster health for each GitLab index.
A first mockup would look like this, but we would have to go deeper into what the different states, potential error messages and solutions for these would be.
![image](/uploads/b5a0c17e4696a1a85e2990f7c30b84c5/image.png)Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/30777Provide support in update MR api to update attribute 'merge_commit_message_wi...2020-11-05T00:50:44ZAmit PaynaikProvide support in update MR api to update attribute 'merge_commit_message_with_description'Below API does not expose attribute 'merge_commit_message_with_description' or similar fields which can be appeared in GIT LOG.
https://docs.gitlab.com/ee/api/merge_requests.html#update-mr
This helps us in Git level automation instead q...Below API does not expose attribute 'merge_commit_message_with_description' or similar fields which can be appeared in GIT LOG.
https://docs.gitlab.com/ee/api/merge_requests.html#update-mr
This helps us in Git level automation instead querying directly to Gitlab server to fetch the description from Gitlab MR.https://gitlab.com/gitlab-org/gitlab/-/issues/30733Support rendering all files for file-by-file reviews2020-12-07T16:33:23ZOswaldo FerreiraSupport rendering all files for file-by-file reviewsIt was discussed at https://gitlab.com/gitlab-org/gitlab-ce/issues/40844#note_199603517 the limitation factor for MR diffs. Meaning that when hitting a [diff collection limit](https://docs.gitlab.com/ee/development/diffs.html#diff-collec...It was discussed at https://gitlab.com/gitlab-org/gitlab-ce/issues/40844#note_199603517 the limitation factor for MR diffs. Meaning that when hitting a [diff collection limit](https://docs.gitlab.com/ee/development/diffs.html#diff-collection-limits) and having a _overflow_ we'll stop persisting `merge_request_diff_files` at some point through the collection, which will lead to a limited amount of diff files, even for a file-by-file review workflow.
From https://gitlab.com/gitlab-org/gitlab-ce/issues/40844#note_199603517:
> Today these limits are mostly applied at the source (Gitaly), so what the client (Rails app) has today is a limited view of the files. In that sense, we might want to reconsider if keep limiting at the source (`enforce_limits: true` to `CommitDiff` RPC) upon `merge_request_diff_files` persistence still makes sense.
Possible solutions:
1. Use a `enforce_limits=false` upon MR diff files persistence, which will stop applying limits at the source (Gitaly), so we'll be capable of persisting all data at `merge_request_diff_files`. Making it possible to request any of those at `/diff_for_path` endpoint. The downside here is that if the object storage persistence is not enabled, we'll put more pressure at the DB size for this table, which doesn't seem ideal. The upside is that we'll be able to support file-by-file reviews for multiple MR versions (old `merge_request_diffs`).
2. Persist `merge_request_diff_files` with an empty `diff` column if it reaches a `overflow`. That solves the problem for falling back to Gitaly at `/diff_for_path` to fetch the diff data, though if we're looking forward to allow a file-by-file diff for multiple MR versions (old `merge_request_diffs`), it'll be a limited approach, given Gitaly won't keep track of all old refs forever.
So in general it depends on how we're looking forward to use this feature and iterate at it in the future. Today we delete old revisions `merge_request_diff_files` automatically when sending a new MR update (e.g. push). So we'd need to change that too, if we opt into the 1st solution for instance.https://gitlab.com/gitlab-org/gitlab/-/issues/30715Improve the parameters passed into `BlobPresenter#hightlight`2023-10-26T17:42:43ZPatrick Bajaoebajao@gitlab.comImprove the parameters passed into `BlobPresenter#hightlight`We're currently using `since` and `to`, but `from:` and `to:` is probably better when refering to line numbers, not time.
The suggestion is to add a parameter object (can be named `LineRange` or `LineSelection`). We can then use and pas...We're currently using `since` and `to`, but `from:` and `to:` is probably better when refering to line numbers, not time.
The suggestion is to add a parameter object (can be named `LineRange` or `LineSelection`). We can then use and pass it along instead of passing 2 separate params.
____
The following discussions from gitlab-ce!31361 should be addressed:
- [ ] @patrickbajao started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31361#note_198605813): (+4 comments)
> Hi @alexkalderimis, can you please review this MR? Thanks! :slight_smile:
- [ ] @alexkalderimis started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31361#note_199834522): (+1 comment)
> We also need a test for the `to:` parameter, wouldn't you agree?
- [ ] @alexkalderimis started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31361#note_199834524):
> Is the expectation that these values should only be provided together? If I supply a since _or_ a _to_, I would expect a performance speedup. Is that expectation met?
>
> Also I am beginning to wonder if it would not be helpful to package these two values, which are related, into a parameter object, perhaps something like `LineSelection.new(since, to)`. This would allow things like:
>
> ```ruby
> all_lines[selection.to_range]
> ```
>
> and have meaningful methods such as `has_lower_bound?` and `has_upper_bound?` or even just `is_bounded?` and `is_all?`.
>
> Further to this, I have issues with the choice of `since` as a parameter name. "Since" is always used for time in English, and page/line numbers are always treated spatially. We say 'from line 2 to line 5'. Is there a reason why we should not use the appropriate preposition here?
- [ ] @alexkalderimis started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31361#note_199834525): (+2 comments)
> This is the kind of expression that a parameter object (e.g. `LineSelection` or `LineRange`) would make a bit nicer, allowing us to say:
>
> ```ruby
> if bottom? && line_range.includes?(all_lines.size)
> ```
>
> Obviously this includes more indirection, but I feel it might make things a bit clearer.
>
> Thoughts?
- [ ] @alexkalderimis started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31361#note_199834526):
> see comment below about choice of parameter names and concept of a parameter object. It might be nicer to add a single parameter here rather than two.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/30651Push mirrors fail when a pre-receive fails for a single ref.2022-07-18T21:03:56ZBob Van Landuytbob@gitlab.comPush mirrors fail when a pre-receive fails for a single ref.Currently when a push mirror (`RemoteMirror`) fails to push one of the branches, the entire mirror is marked as failed. While the later branches are not updated.
I think we should handle this on the gitlab-ce~11839077 side, pushing all ...Currently when a push mirror (`RemoteMirror`) fails to push one of the branches, the entire mirror is marked as failed. While the later branches are not updated.
I think we should handle this on the gitlab-ce~11839077 side, pushing all the changes we need to push separately and return a response instead of an error if one fails. We'd need to handle the new response on the Rails side.
Inside the response we could report what was pushed and what failed, so we can show it to the user so they could manually intervene if necessary. And we don't fail the push if one of the branches failed.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/30638Avoid scheduling Remote Mirror updates if an update was already scheduled2022-09-21T09:20:40ZBob Van Landuytbob@gitlab.comAvoid scheduling Remote Mirror updates if an update was already scheduledRight now, we schedule a new `UpdateRemoteMirrorWorker` for each update we get. If an update was recently started, we schedule it a little bit in the future, so the currently running one can finish first.
If another update happens before...Right now, we schedule a new `UpdateRemoteMirrorWorker` for each update we get. If an update was recently started, we schedule it a little bit in the future, so the currently running one can finish first.
If another update happens before the the job scheduled in the future runs, then we'll schedule another one a little bit further in the future.
Those last jobs become no-ops, since when the first push mirror runs, it will already have included the changes.
We should avoid scheduling these no-op jobs. We could do this by keeping track of the `jid` if we schedule a job in the future, then we can check the status of that job to determine if we need to schedule another job.
___
The following discussion from gitlab-ce!31247 should be addressed:
- [ ] @reprazent started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31247#note_199511849):
> This could still be optimized: If we keep track of the `jid` that was scheduled and check if it's still appropriate before scheduling anything, we could avoid scheduling multiple no-op jobs.
>
> But I'd rather deal with that in a separate issue.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/13222Move EE spec mock data files to the corresponding CE file2020-08-14T11:12:28ZPaul Slaughterpslaughter@gitlab.comMove EE spec mock data files to the corresponding CE fileThe following discussion from !14520 should be addressed:
- [ ] @pslaughter started a [discussion](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14520#note_199186632):
> **tech debt:** I just realized that this copy is in...The following discussion from !14520 should be addressed:
- [ ] @pslaughter started a [discussion](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14520#note_199186632):
> **tech debt:** I just realized that this copy is in `ee/` while the source is not :disappointed:... Unfortunately, it will not be that easy to import from `spec/frontend` while in `ee/spec/frontend` so I think this is something we should handle in a follow up MR. I'll create an issue for this.
In addition, we will also need to support something like a `spec` alias in our Jest config.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/13221Export factory function in spec file `diffs/mock_data/diff_file.js`2020-08-14T11:12:28ZPaul Slaughterpslaughter@gitlab.comExport factory function in spec file `diffs/mock_data/diff_file.js`The following discussion from !14520 should be addressed:
- [ ] @pslaughter started a [discussion](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14520#note_199186506):
> **tech debt:** We should probably refactor our mock...The following discussion from !14520 should be addressed:
- [ ] @pslaughter started a [discussion](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14520#note_199186506):
> **tech debt:** We should probably refactor our mock data to export a factory function instead of raw object so we don't have to clone it... I'll create an issue for this.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/30624Web IDE Editor Improvements [Panes and Preview]2023-04-26T10:15:11ZMike Rochefortmroche@omenos.devWeb IDE Editor Improvements [Panes and Preview]### Problem to solve
Limitation of utilizing the entire screen real-estate for a single file, as well as making the user have to flip back and forth between the Edit and Preview panes.
Allow editors to work on multiple files at once wh...### Problem to solve
Limitation of utilizing the entire screen real-estate for a single file, as well as making the user have to flip back and forth between the Edit and Preview panes.
Allow editors to work on multiple files at once while in the editor view, as well as provide realtime preview of Markdown and reStructuredText documents.
### Intended users
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
Any developers or users that find the need to edit multiple files at once or see the changes they are making who feel it's faster to do it from the Web IDE and don't want to make syntax errors.
### Further details
<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
Enhance the capabilities of the IDE to introduce fairly common basic functionality found in most client side editors and some cloud ones.
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
Introduce the ability to work on multiple files simultaneously in the Web IDE, either through vertical splits or something as simple as a dual pane editing mode. It would also be great if the Preview functionality could be handled in a tab of a separate pane (similar to the way VSCode works when choosing to preview a Markdown or reStructuredText file) so that users editing markup files would have the ability to see the results of their edits. This could help reduce accidental syntactical errors that could possibly require a follow-up commit.
These kinds of functionality would make the Web IDE a good alternative to make quick edits to multiple files while on the go or for users that catch something while browsing source without needing to make the edits locally then pushing them up.
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? -->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements -->
Descriptions of the features and how to use them would need to be added here: https://docs.gitlab.com/ee/user/project/repository/web_editor.html
### Testing
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
### Links / referencesBacklog