Hide file browser and display options from empty state changes tab
What does this MR do?
Hides the file browser and display options on the changes tab of merge requests with no changes.
Scenario | Before | After |
---|---|---|
0 commits, 0 changes | ![]() |
![]() |
2 commits, 0 changes, 0 versions | ![]() |
![]() |
2 commits, 0 changes, 1 version | ![]() |
![]() |
2 commits, 5 changes | ![]() |
![]() |
individual commit | ![]() |
![]() |
comparing same version | ![]() |
![]() |
Screenshots
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Closes #256035 (closed)
Merge request reports
Activity
changed milestone to %13.5
added UX devopscreate groupsource code typebug labels
added frontend label
Reviewer roulette
Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.
To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited, or the chosen person is unavailable.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, mention them as you normally would! Danger does not automatically notify them for you.
Category Reviewer Maintainer frontend Savas Vedova ( @svedova
) (UTC+3)Tim Zallmann ( @timzallmann
) (UTC+1)test Quality for spec/features/*
Mark Lapierre ( @mlapierre
) (UTC+11)Maintainer review is optional for test Quality for spec/features/*
If needed, you can retry the
danger-review
job that generated this comment.Generated by
DangerEdited by 🤖 GitLab Bot 🤖removed frontend label
assigned to @mvanremmerden
added frontend label
- Resolved by Pedro Moreira da Silva
@pedroms Would you mind having a quick look whether this is as straightforward as I thought, or whether I might have overlooked some edge cases?
assigned to @pedroms and unassigned @mvanremmerden
Bundle size analysis [beta]
This compares changes in bundle size for entry points between the commits 81832751 and 3467ecc3
Special assetsEntrypoint / Name Size before Size after Diff Diff in percent average 3.05 MB 3.05 MB - 0.0 % mainChunk 1.89 MB 1.89 MB - 0.0 %
Note: We do not have exact data for 81832751. So we have used data from: bfb97c64.
The intended commit has no webpack pipeline, so we chose the last commit with one before it.Please look at the full report for more details
Read more about how this report works.
Generated by
DangerEdited by 🤖 GitLab Bot 🤖- Resolved by Marcel van Remmerden
@a_akgun When looking at the failing test, it seems like it's checking a couple of merge request diffs from this file. When loading these manually in the GDK, the first three (with 35, 36, and 37 as diff) only shows this endless loop.
The other one with
?diff_id=20
works perfectly fine, and loading the changes tab manually also works.I'm wondering whether there might be something wrong with the mock data? Do you happen to have any idea how to debug this?
Edited by Marcel van Remmerden
added sectiondev label
assigned to @a_akgun
assigned to @mvanremmerden and unassigned @pedroms
unassigned @a_akgun
@iamphill it seems like the jest 2/4 test is failing because it expects the file tree to be present even when there are no changes. As you were the one creating this test, and modifying test data and scenarios is still one level too high for me, would you mind having a look for me to see whether my assumption is correct, and what we could do to fix that?
assigned to @iamphill and unassigned @mvanremmerden
- Resolved by Marcel van Remmerden
@mvanremmerden Pushed a fix
assigned to @mvanremmerden and unassigned @iamphill
@pgascouvaillancourt Would you mind reviewing this change?
assigned to @pgascouvaillancourt and unassigned @mvanremmerden
- Resolved by Marcel van Remmerden
- Resolved by Marcel van Remmerden
- Resolved by Marcel van Remmerden
- Resolved by Marcel van Remmerden
Looks good overall, thank you for this @mvanremmerden!
I left a few suggestions for you to consider. Back to you for now!
assigned to @mvanremmerden and unassigned @pgascouvaillancourt
added 1 commit
- 23c3f3c7 - Move empty state check up to parent component
assigned to @pgascouvaillancourt and unassigned @mvanremmerden
- Resolved by Marcel van Remmerden
LGTM! Thank you again @mvanremmerden!
I left a last nitpick but I'll approve as is to not delay this further
assigned to @mvanremmerden and unassigned @pgascouvaillancourt
added 1 commit
- 23c3f3c7 - Move empty state check up to parent component
assigned to @ohoral and unassigned @mvanremmerden