Loading AppWe are loading some Thanos level javascript...
Current Time 0:00
Duration -:-
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
    • Chapters
    • descriptions off, selected
    • captions off, selected
      View complete GPT-powered meeting notes
      Skim through the meeting in minutes by GPT-powered summary, notes, action items and more.
      Xavier Antoviaque
      Apr 08 2025, 3:00 PM
      English (Global)
      Overview
      The Sprint Planning and Retrospective meeting for the Whitebox project focused on addressing critical issues with Browser Stack, where Avinash highlighted inconsistent test failures, leading to a proposal to explore Lambda Test as an alternative. The team discussed the challenges of plugin testing, with Avinash investigating various approaches and a decision made for him to commit partial code for Milos to review and create a proof of concept. As part of their sprint planning, the team reported progress on merged tasks and reassigned task 102 from Avinash to Milos, with efforts to implement local sandbox tests. Key action items were assigned to team members, including tasks for Lambda Test implementation and plugin testing strategies, emphasizing collaboration on code reviews to maintain momentum for the sprint.
      Notes
      🐛 Browser Stack Issues (02:44 - 15:01)
      • Avinash reported significant reliability issues with Browser Stack testing
      • Tests failing inconsistently without code changes (9 tests failing one run, 30 the next)
      • Adding more retries makes the situation worse
      • Proposal to switch to Lambda Test as an alternative solution
      • Lambda Test requires tests to be written differently with browser objects created manually
      • Xavier suggested testing one test with Lambda Test before converting everything
      • Milos recommended ensuring any new solution will support local device testing in the future
      🔌 Plugin Testing Challenges (15:02 - 27:00)
      • Avinash spent extensive time investigating plugin testing approaches
      • Most examples expect remote applications to be independent, unlike Whitebox's setup
      • Avinash built tests using Federation system but couldn't integrate them with the host test suite
      • Shared link to webpack maintainers' example as potential approach
      • Decision to have Avinash commit partial code for Milos to review
      • Milos suggested running Express server or development server to serve test components
      • Xavier recommended using actual development/production servers instead of creating new test servers
      • Team agreed Milos would create a POC to determine the best approach
      📊 Sprint Review and Planning (27:01 - 33:27)
      • Avinash completed merging tasks 133 to 195
      • Milos completed his concurrent transition work for the Wizard component
      • Both team members making progress on their book reading assignments
      • Plan to replace Browser Stack with sandbox tests
      • Task 102 reassigned from Avinash to Milos
      • Avinash to create a task for Lambda Test testing to replace Browser Stack
      • Xavier emphasized completing all assigned tasks this sprint
      🔄 Next Steps and Module Federation (33:27 - 37:43)
      • Task 209 contained within task 207
      • Milos to focus on testing issues as priority
      • Milos may begin work on empty slot behavior if time permits
      • Team confirmed Federation system is working stably
      • Xavier offered to review WIP code and asked Milos to review as original author
      • Team to ping each other when ready for reviews
      Action items
      Avinash Sah
      • Write a discovery task for Lambda Test implementation (12:09)
      • Enable local sandbox tests as an alternative to Browser Stack (14:37)
      • Commit plugin test code with clear documentation of what works/doesn't work (23:04)
      • Update description of task 102 explaining current status (30:36)
      • Create task for Lambda Test testing to replace Browser Stack task (31:27)
      • Complete book reading assignment (29:07)
      Miloš
      • Review Lambda Test discovery task description (12:09)
      • Take over task 102 for plugin testing implementation (30:22)
      • Create proof of concept for plugin testing using development server (27:01)
      • Complete task 209 (34:02)
      • Work on empty slot behavior if time permits (34:13)
      Xavier Antoviaque
      • Review Avinash's updates for tasks 133-195 (27:48)
      • Review WIP code (36:53)
      Hello. 
      Hey. Hi. Hello. Okay. Pretty okay. 
      Yes. Or was it going this way? Because you seem to have been struggling a bit. No. 
      Yeah. I mean, I thought Milos would be joining today. Did you not join? 
      I think you should. Yeah, yeah, yeah. 
      So I was exploring a lot of ideas and. Hey, how was the vacation? 
      It was great. I brought my laptop and stayed there for like two more weeks. 
      Good. Where are you? What? 
      Sorry? 
      Where are you exactly? 
      Back home. 
      Oh, you went back home. Okay. You wish. 
      Yeah, yeah, that would have been great. Like, I really loved it. It was perfectly safe, which I did not expect. And there were those gates that you can see on the. And on the. On the pictures. They are everywhere. It was really nice. 
      Nice. 
      Yeah. All right. 
      Yes. 
      Maybe you can recap the last two sprint. Actually, we'll have a bit more context. 
      I mean, last to last. I was away because I was not well. So I was just working for. During the ending of the, like Monday and Tuesday, that is end of the Sprint. And I was pretty much trying to figure out how to run tests for the plugins. Last week I was more focused on doing this. First, I think I should mention about the browser stack situation, because I tried to debug that a lot and I think we need to switch to maybe something like LambdaTest, who is like the closest alternative to it. Because I tried to debunk that a lot and nothing makes sense. Maybe it's their network issue within their. Whatever devices they are using or whatever the server farm they have. Or maybe their devices are slow or just nothing is predictable. 
      Because I would run a test and for instance, nine tests are failing and I would not change anything and I would run another test and suddenly now 30 tests are failing for no reason. And when I see the. Like the videos, sometimes the URL is not loading, sometimes it's for some reason visiting localhost 3000, which it shouldn't. Should not even visit. Then sometimes it's just stuck at loading. And adding more retries is not helping either. And from what I've observed, it is just making the situation even worse. For some reason I'm not sure how they are handling the retries because I think instead of retrying a failed test, instead they spawn like three. If we have mentioned three retries, then they are spawning three tests and I think that overwhelms the server in some way and we don't get even a single request passing. 
      So there is a lot of issues with browser stack and I could not really find any sane solution other than maybe I think we should Think about switching to someone else. I tried to test Lambda test which was the closest alternative. Closest alternative everyone is mentioning on the Internet. But they expect tests to be written in a different way. They expect browser object to be created by us and then tests they want to like want us to connect to their grid through websockets and then write tests using those things. So does need a bit of a rewrite because currently we are using the describe and test and expect that is exported by playwright tests and according to their document I couldn't find any documentation that could just make it work out of the box. So that is the situation with 236. 
      But do we have any reason to believe that it will be more reliable with Lambda test? 
      It's one of those things that I think we'll have to test and then we will know. But according to the people on the forum, it's faster and more reliable than browser stack. So it is a thing. It is a possible upgrade that should work, that has worked for people on the Internet. So maybe it's worth giving an attempt. I didn't just went and rewrite everything and just tested it beforehand because the tests would require a certain amount of change and I thought it would be worth discussing it first before went that route. 
      So yeah, it might be worth testing with the one test at least to see if it is like the first or it works if it does work if we do get a reliable result on that test or not before maybe converting everything. But it's true that it has been a pain in the ass and yeah like reliability for end to end testing is always a bit of an issue. I don't think I've ever seen it like working perfectly or like in all situations. So there might be also a bit of adaptation on how we test also on our end. But it's true that if browser stack is not reliable maybe we need to study something else. 
      Yeah, I agree. Yeah, mostly I think it's. Yeah, yeah please go ahead. 
      Just if we make those changes like I'm gonna write so we don't forget but what we discussed like a few months back to maybe use it as a troubleshooting mechanism since it's going to be offline hardware device. Just to take that into account when we develop that we also probably want to run the test to be able to run the test suits locally on the device. That's a stretch but maybe just to keep in mind when we switch how do we do it like so we don't introduce something that's not gonna. That's gonna prevent us from doing it later without additional rewrites. 
      I think if we write everything from the context of using a browser and connecting to a grid directly, then it should leave us room, leave us the like allow us to change the providers anytime in future. Because the currently how it's written, it's very specific to how browser stacks, how browser Stack expects the test to be. But if we have written everything in a more conventional way where we are exposing the browser object and testing against it, then it's. Then, I mean it's a more open standard than what we have been doing with browser Stack. So if that doesn't work, lambda stack doesn't work, then it's just a connection to a grid. So if the grid doesn't work, then we can switch to any other grid and it would just be a single line swap. 
      I mean. Yeah, that makes sense. Like I've been thinking a bit about basically what browser stack is doing is they are kind of monkey patching the test function. If I get it right. 
      Yeah, yeah. 
      Technically we can do something similar instead of. Well, not monkey patch but like the. The playwright has that thing where you import test function, then rewrite it or something as the before all before each, whatever to use it and then you import that test function to use in tests. So technically we can do it as a middleware kind of thing. 
      Yeah, that. That could work. Yes. Basically what we just want is a way to connect to a grid and expose the page and then everything just works. 
      Yeah, that'd be great. 
      All right, so Avinos, do you want to write a discovery task maybe for this and Milos, you would review the description? 
      Sure. 
      Yep, that works all right. 
      And that can be maybe. So for that task it won't close actually the task because we still have fanning tests. So how do we deal with that in the meantime? 
      Yeah, that's. Now let's. Now the issue is the plugin test and without it we can move forward. 
      Which is a big issue. Well, there's the plugin test, but even browser stack, like what do we do in the meantime? Because it's not going to be converted in like out of like. And especially because we. The rest of the tests are on shamble right now. I'm a bit worried that in a month when we have like converted everything, we just have to rewrite all the tests basically because nothing is running right now. 
      What we could do is for the time being we could write a wrapper maybe like rent a VPS or something and Write a wrapper because the test works locally. It's just that it is not working with browser stack. So instead either we could just add a Checklist before the Mr. That please, whoever is reviewing, just run these tests and let us know if everything is working for everyone or other. If we want to automate that through CI then we could just write a wrapper around that and simply test run the test on some server and let the CI pass. 
      I mean we can edit the CI like we. I. I don't know why we didn't add it. I guess because it required the whole sandbox and then I just added it as a step after the sandbox is deployed to directly invoke the browser stack. But since we have the sandbox available, we can just run it at the same time where we ran when we ran the browser stack. We can run it from the CI machine. 
      I mean, yeah, it's headless so it should technically run within the CI without needing anything else. 
      Yeah. I guess the reason why I didn't tell it is because we it involved phone devices which we cannot emulate. But just having anything is better than nothing. So I can do it in like one hour. 
      But that's the test that you have currently. 
      Yep. So I could enable that. That would be an easy thing to enable. 
      Yeah, that could, that could be a good way to close that task like switching from stack to like a local sandbox test and creating that follow up task to replace broader stack or at least do a discovery on that. That sounds good. 
      Okay. 
      All right. 
      Okay then about the plugin tests. Yeah, the elephant in the room. 
      Yeah, I read the emails. I couldn't not do it. 
      Yeah, I mean I, I went through a lot of examples and I tried to brainstorm this a lot last week. How everyone is doing it is that they are expecting these remote applications to be their own applications that is unaware of the host application and they are basically adding tests within that project and testing everything out. Now the issue with doing this on our end is because we are dependent on the host application for components. So I mean we could do certain monkey patches, but maintaining that doesn't really make sense as a project scales. And then I tried to create some kind of a bridge that would send all the tests over the URLs. I was able to build all the tests using the Federation plugin Federation system that we have right now. 
      Now I was trying to brainstorm some way to import this with these tests, build tests within the host test suite and run them. But I just could not make that work. As of right now, I'm not sure if it, if it is even possible. I could find, I could not find any example that is using the virtual way of connecting to the remote apps that we are using because everyone is just connecting it at the build step. They are mentioning it in the config and writing all the tests within the host application. As I told. As I discussed last time, I found only one example. I am sharing the link. 
      This one is from the webpack maintainers and our test suit should ideally look like this where, I mean if and if we are going to write the tests within the host application for the plugins as well. But yeah, I mean I just could not wrap my brain around how we could do it in our situation. Maybe we could talk to the maintainers of the federation. They have like there was some link where they were providing consultancy because I, I mean at least I am pretty stuck right now because I don't find any obvious way of. Basically I'm able to build them now, but I'm not able to import them within the suite and run the test. 
      Would you be able to put what you have found and tried, even if it doesn't work, into a merge request so that we can have a look. Yeah. And explain exactly where you're stuck, the things that work, the things that don't work. Because that might be easier. I think like at a high level now it's probably going to be difficult because you have dug into that way more than we did. 
      Yeah, Yep. I could actually. It's all I was trying out in different branches. I will commit the one that was partly like partially successful and just mention it there and you guys could look at it. But yeah, I mean I wanted to know if Milas had any ideas about this because he has worked on this more than me and I think I get the whole system pretty well at this point. But I'm. I'm sure there are still gaps because I was not the original writer of this and Milestone probably would have dug into this more. So I was. I wanted to know if you had any ideas of how we could possibly do this. 
      I mean we do have to have the entire build in with at least the core plugins. So I guess it might make sense to as part of a test suit to have a, like collect all the components, build them and maybe expose them on dummy server. Like that is just going to serve the build folder. That is going to increase complexity quite a bit. But that is the only way I can think of that basically replicates the production 100%. Because technically we could write unit tests directly for the components themselves, but that would not go through the module federation. And then we could technically be susceptible to bugs that, that are never going to be caught in the, in the tests. 
      Because as there is some of those issues about the plugin federation thing that is obsoleted that we might want to replace, probably replace. Like, I don't know what kind of bugs they are, but like I read that there is something related to Zoo stand that sometimes gives problems. And the way we are go, we started doing it with the exposed global objects through the window. Like maybe we won't be susceptible to those bugs, but like that is the thing that we won't know until they happen. So if we're going to build something, I would not work around that, but rather go through the actual thing. Like, I don't like the complexity that it would add, but I think it's the only reasonable way to go. 
      Maybe not server, maybe do it some other way to serve those specific files to the test environment, but definitely do a whole build. 
      I think, yes. I mean, I think in that case the tests, even if they are supposed to be unit tests, will have to replicate or use actually, or bring up most of the infrastructure. At least the infrastructure that is necessary to get something working right. Like the unit tests in themselves will probably not completely work on their own. So it would have to be functioning within the kernel would have to be loaded and would have to be loading the different federation modules, or at least the dependent ones for running that. I think it's not really going to be running in complete isolation in that case. So it's going to be intermediate between unit test and integration test in a way. I think it has to be right. 
      Yeah, I mean we're kind of already doing it for the Python code for the plugins. 
      Yep. My approach was the same and I was able to serve all the tests. But the main issue that I'm currently facing is how I would load all that in this test suit of the front end. Let me just commit all that code because you would have a better idea when you look at it. 
      Yeah, again, maybe that can because it's like if you spent a whole week on it and you weren't able to get a solution, I doubt we'll manage to get it in 10 minutes now. But if you commit that, explain clearly where you are what works, what doesn't work. Maybe we could actually reverse that task for this week where Milos, you take it on if you want to and try to work on that and getting a solution if you can and at the minimum do a review, but try to get something more if you can and then we see where we get with that. 
      I mean, sure, if I was doing it so we're on the same page so we don't go off in a direction we don't want to go. Like I would probably do something like before all tests, run a script. Well, not the script, run code, JavaScript code. That's just going to run an Express server so we don't additional processes and everything to the test suit for the unit test run a test server through Express. That's going to solve that to. To serve that. And then I will still have the context just to load the federation through it and then the import white box component should just work. Hopefully. 
      I'm not sure I completely got what you said, but if you, if we are spinning up at a test server, can we just spin up the actual servers like the actual development or production server on the front end and back inside rather than do a separate thing that we would also have to maintain and that might have their own quirks and differences. 
      Okay, sure. I mean, I don't know exactly how I would go with that because ideally, I think because of the, for example, the, not CSRF but the course headers because of that. I would really like to eventually get to the point where development server also uses NGINX and everything goes on the nginx even on the development container. So I'm not sure how exactly that would fit in right now, but maybe it makes sense. Like, I don't know what did you have in mind about developing JSX right now in this print, but maybe go towards that to get the development server on the NGINX and then do that as well. Like as the part of the same effort. Like I don't know, that kind of drags it out and I don't want to drag this out, but I don't know. 
      Yeah, I mean if it's on the dependency path, why not. If it's something that we can leave aside to keep the testing smaller, I would prefer that because then we tackle one thing at a time rather than make the task bigger. But if it's, if it's. That's. I would leave that to you. If you can't avoid doing the NGINX stuff at the same time. Why not? But if we can keep it smaller, it's already pretty big. 
      I mean, I guess I can try doing just with the development server, create like poc that if it works out of the box, great. If it doesn't, I'm just going to hack it with nginx Temporari and then just so that we can actually get it running on the development machine on our own local host, if nothing else, so that we have some certainty that it actually works, that we're getting somewhere. Does that make sense? 
      All right, sounds good. All right, so let's do that. So let's see, for the sprint, I'm going to the current Bob so that we see a bit exactly where we are. So here we go. So here we close some stuff here. But that was last sprint. I don't think there was anything new. This print. So this. I saw your comment, Avinash, that you had finished updating. I didn't get to read review before the meeting, but at least this should be done, right? I mean, those two actually. Right. 
      Yeah. I've merged everything from one double three to 195 and I have addressed most of your comments, I think. Sorry for doing this in the very end. I was just so distracted with the other tool. 1. 
      Sorry. 
      Like, this was a mess. This. This print was a mess. I'm sorry. 
      That's okay. We'll try to get that sorted. But at least if already it's in the reviewable state, that would be something for this print. So this is still blocked. Those two. The books. Have you finished your books? I feel like the teacher at school. 
      Nice. 
      Cool. All right. So that's great. 
      Yeah. Like the concurrent thing, I. I regret not being able to test stuff, but the. The transition thing, like, it. It really. I think I have finally assembled the piece like on the Wizard. I eventually wanted to be like a carousel moving between the steps, and I was thinking how I can do it and that's. 
      That's the way to go on it. Okay, that. That's great. All right, cool. What about you, Avinash? 
      For me five. I'm at fifth chapter and half of it is done. So, yeah, I thought I would get done with it within this week, but because of those two, I couldn't. I'll get done for sure within the sprint. 
      All right, I'll take you on your word on this one. And actually, let's make sure that this week you're clean on your sprint because you haven't been in a few sprints. I Know that there was also circumstances for that, but I think it's important to catch back the best there. 
      Okay. Yep. 
      All right. So this one we just talked about those two actually, we just talked about it. So this one you'll work on what we talked about switching to like a sandbox test and then you can pass it into review. And this one? Yeah, like what you can do is like push some merge request with what you have and then reassign it to Milos. 
      Yep. I've pushed what I've worked on a branch already and I've updated the description. Okay. So all right. 
      I think you have already done all of that. I guess we can reassign it. Just. Yeah, that's one on 102. Is that right? Okay. 
      Yep. 
      Okay. And did you put a bit of a description of what works, what doesn't work and etc. So that means. 
      Not yet. Not yet. I'll get done with it after the meeting. 
      Okay, sounds good. So Milos, you're still good to get that one. 
      Okay. 
      So that address what is in the Sprint. Now what about the next tasks? 
      Maybe I should test the suite with Lambda test so we can move to that for the Sprint. 
      Okay, so does that replace some of the tasks that we have here? For example, this one, that's probably not something we relevant anymore. 
      Yep. 
      Okay. Do we have any other stack stuff in there? Okay, so then what you can do is that you create that task in there and that will replace this one, basically this one. All right, sounds good. Anything else for you, Avinash? 
      I think we are. We could start with the implementation, but yeah, those won't be merged because we don't have tests running it. Implementation of for plugins, GPS plugins and the other things. 
      You mean? Oh yes. But yeah, the thing. Remember I like. I really like this Sprint to be clean. So only take things that you can complete and push for review this week. Like if you have time, you can work ahead on some of those other tasks obviously. But just want to make sure that everything is completed this time. 
      Okay then let's just. 
      I just let's. 
      I won't take anything more from next week. Hopefully when tests are moving, I would be able to take more things. 
      Yeah. Yeah. If you, if you do finish the task, if they get into review and etc, like let me know which task you'd like to get on. It's probably going to be the ones in the next spring column and we can do with that. 
      Yep. 
      All right. What about your Minos? 
      So 209 is basically test is basically contained within 207, right. Because like if we have. 
      Yeah. 
      One, then we have the other. 
      Yeah. 
      What? 
      Sorry, I assigned this one to YouTube 209. 
      Yeah. Yeah. 
      Okay. 
      I don't know how much that's gonna take, so I guess I'm gonna take just that one. So we don't start with this pillow. 
      Yes, that. That's a good idea. Let's take good habits. 
      Yeah, I don't really want to do that. And I was reading on this empty slot behavior and I don't want just that to be a whip. Maybe an entire slots. The slot system itself should be a whip. So I don't want to take it as a official thing for the Sprint, but if I have time remaining, I was thinking of starting to work on that because the air thing, it was just my way to test Federation out in the beginning and then I just left it out because I had issues loading when I started developing it. But yeah, it makes sense to have a required and optional slot and everything. So I guess I can start with that a little bit. But I will not get it into the final phase, definitely. 
      No, I think that's. That's a great approach to secure the testing part because that's blocking other things quite a bit and then work ahead on that one if you can. Sounds perfect. 
      Okay. 
      All right. Any other things for this Sprint that we need to look at? I think you're both good with your. The content of your Sprint, but. 
      Have there been any issues with the. Apart from the testing thing with the Federation? Like, I don't know how much you. You played with it, but like, is it stable from. 
      I. I was playing with it for quite some time and I mean, from my tests it is very stable. So it's just a matter of getting test figured out and I think we are good to move forward with this. 
      I haven't played a lot with it, but every time I played with it seemed to be reliable. I haven't had any bugs so far, so. Yeah, good job. 
      Glad to hear that. I was scared I'm gonna come back here, you're gonna tell me nothing works, that could happen. 
      But no, I think this one is good. I mean, I guess we'll see when we implement the other plugins. That would be the best, right? All right, sounds good. So I guess we're good for today, right? 
      Yeah, I'm just gonna. I'm moving this empty slot behavior to the top of the list, so I see it. 
      Okay, sounds good. Well, let's do that. I'll have a look at the whip either tomorrow maybe. Also Milos, have a look. Since you were the original author, that might make sense that you do one last pass also only that will be merged and then the rest. Don't hesitate to ping when it's when you have stuff or if you need comments and etc, then it will be good to start having a look. There is not a lot of stuff in review this week, so I think we can review a bit ahead. There are stuff ready. 
      Okay. 
      All right. Well good luck then and welcome back. Milos. 
      Thank you. 
      Where we get this print? All right. Have a good day. Good evening and see you soon. 
      You too. 
      Yeah, bye. 
      00:0000:00