[service][web] Allow downloading logs from web UI#379
Conversation
dgdavid
force-pushed
the
provide_logs
branch
2 times, most recently
from
917adfc to
2151bbb
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Basically, for making it quicker when closing.
Instead, just mock needed parts of the layout when needed. This way, test will be more explicit and less fragile.
As it's done in the rest of sidebar actions.
Now it's a one-off click link instead of forcing the user to click twice in order to collect & download the logs. It shows information about what is going on too.
dgdavid
changed the title
Don't worry about those sizes by now, most probably they will be changed a few times more before reaching a certain level of stability.
imobachgs
left a comment
imobachgs
left a comment
There was a problem hiding this comment.
In general, it looks good, although I do not feel comfortable with the naming at all.
| const link = await screen.findByLabelText(/Open/i); | ||
| const clickEvent = createEvent.click(link); | ||
| fireEvent(link, clickEvent); | ||
| expect(clickEvent.defaultPrevented).toBe(true); |
There was a problem hiding this comment.
The real problem is that opening the sidebar takes you to a different URL. If there is no other way to test that, I am fine with it. Otherwise, we should not extend this kind of tests to other components (just saying).
There was a problem hiding this comment.
Sure, this is a very specific test that should not be used as an example for other components. But I want to keep it because the intention is to avoid a regression when opening the sidebar: I myself faced the problem of accidentally navigating from the Product Selection page to the Overview when opening the sidebar.
Hopefully, this will change in the near future, after fixing the missuses of button and hiperlink.
In no particular order, below are the next UI changes I'd like to make
To fix the misuse of buttons/links
https://ashleemboyer.com/blog/should-i-use-a-button-or-a-link
^^^ An excerpt from #391 description. ^^^
I see (and share) your concern about the use of fireEvent, but I think we're making a legitimate use of it here. From the @testing-library/dom-testing-library API documentation:
Note
Most projects have a few use cases for fireEvent, but the majority of the time you should probably use @testing-library/user-event.
Also, from the guide-events documentation
Based on the Guiding Principles, your test should resemble how users interact with your code (component, page, etc.) as much as possible. With this in mind, you should know that fireEvent isn't exactly how the user interacts with your application, but it's close enough for most scenarios.
That's why, as you said, we should not extend this kind of tests to other components.
Co-Authored-By: Imobach González Sosa <igonzalezsosa@suse.com>
Also add missing unit tests to that part. Co-Authored-By: Imobach González Sosa <igonzalezsosa@suse.com>
https://build.opensuse.org/request/show/1066104 by user IGonzalezSosa + dimstar_suse - Version 0.7 - Update the list of patterns to install for Leap Micro 5.3 (gh#agama-project/agama#427). - Better handling of software repositories (gh#agama-project/agama#414): * Report issues when reading the software repositories. * Inform the user about the software proposal progress. * Do not try to calculate a proposal if there are no repositories. - Use the upstream version of D-Bus ObjectManager (gh#agama-project/agama#245) - Save logs and provide the path to the file (gh#agama-project/agama#379) - Implement validation of software proposal (gh#agama-project/agama#381) - Check for installed packages in the target system, instead of the installation medium (gh#agama-project/agama#393). - Simplify the network configuration to just copying the NetworkManager connections and e
https://build.opensuse.org/request/show/1066106 by user IGonzalezSosa + dimstar_suse - Version 0.7 - Do not use a proxy to get the errors lists (gh#agama-project/agama#424). - Add live reloading feature for easing the front-end development process (gh#agama-project/agama#419). - Fix storage section crashing when proposal is not ready (gh#agama-project/agama#418). - Better handling of software repositories (gh#agama-project/agama#414): * Report issues when reading the software repositories. * Inform the user about the software proposal progress. * Add a button to reload the repositories (gh#agama-project/agama#388). - Added a button for displaying the YaST logs (related to gh#agama-project/agama#379) - UI fixes (gh#agama-project/agama#401): * Add a fallback height for the layout * Fix some miss-alignments * Add missing icon * Ensure tooling serving and loading fo
5 participants
Problem
There is missing easy way to get logs from d-installer.
Solution
Provide a D-Bus method that returns the path to logs. As a first step, it will just provide YaST logs, but it can be extended in the future with whatever is needed.
Testing
PR's side effects
For placing the button in a sensible, not intrusive location, we have had to introduce the basic infrastructure for a sidebar controlled by the hamburger menu icon and move few things there. I.e., we have set the foundations for #395. So reviewers: please do not pay so much attention to the current look & feel and add your comments in the linked issue.
Another side effect is that we had to remove the use of the
Layoutcomponent in the renders test utils functions. Now, the below line has to be used when testing a component making use of the Layout slots (a.k.a. React Portals). Believe or not, it makes testing less painful.^^^ Somehow related with #392 and #392 (comment)
Future Steps
Screenshots