fix(ci): use a local test server for fetch test#207
Conversation
|
ah, I didn't see this PR before filing #209. I think we should move away from that remote URL entirely instead of trying to paper over it. One reason is that it seems like the failures show up somewhat consistently for all tests of a run if they show up at all: I usually see all of |
|
Yeah, looks like we have the same intent there -- updating the code to use a temporary server we control is likely the best solution here, skipping the stopgap. |
ef69aee to
8bcaba2
Compare
832638a to
6c9382c
Compare
Signed-off-by: Victor Adossi <vadossi@cosmonic.com>
6c9382c to
7aa0182
Compare
|
Hey @tschneidereit can you take a look at this? should be ready to go now |
e13a19b to
3490a1d
Compare
Signed-off-by: Victor Adossi <vadossi@cosmonic.com>
3490a1d to
e891103
Compare
|
@vados-cosmonic thank you for this! It seems like there are still some Windows issues to address, but once those are dealt with, I'm eager to get this landed. |
Signed-off-by: Victor Adossi <vadossi@cosmonic.com>
|
Ah apologies there -- windows paths were being wonky, but I didn't need to do that dynamic import anyway! Should be good now |
tschneidereit
left a comment
There was a problem hiding this comment.
I left a comment in-line on test state management. I'd like to discuss that more before landing this.
Signed-off-by: Victor Adossi <vadossi@cosmonic.com>
This test seems to be flaky in CI mostly because it relies on a remote URL.
What I'd like to do here is use a server that we manage (similar to how
jcodoes, moving over some utility functions from there) that will definitely return JS, but it's not clear how the exportedsourcewas intended to be used (is it OK for that to become a function that takes a URL?).In the meantime, we can at least retry the test while it depends on a remote URL (and we don't have any testing frameworks like
vitestset up).