-
Notifications
You must be signed in to change notification settings - Fork 535
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(test-tools): Make initial port configurable and update deps #23202
Conversation
@@ -1,3 +1,12 @@ | |||
#!/usr/bin/env node |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd really like a --help
mode or something that tells me about the command line argument. It's not very discoverable unless I also read the part of the README that mentions it can take an argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point, I'll add handling for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've always hoped we can subsume this functionality into one of our other build-tools packages. Seems ridiculous to have a separate package just for this command. Can't benefit from any of our shared tooling infrastructure either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally agree, I was halfway through making it into standalone mjs scripts when I realized that in order to use the getTestPort
function, packages would have to import the file by path, and each one would require a potentially different path in each case (depending on how "deep" each example package is, for example).
I also considered making test-tools part of the client release group, to avoid the change-publish-consume dance, but then noticed build-tools also uses it right now. Although now that I think about it, it probably doesn't need to? It has no jest tests... So making this a @fluid-private
part of the client release group starts sounding like a good option.
The only caveat to all this is that I still need to publish a version with the fix so we can consume it in LTS (or we also merge it into the client release group in LTS at the same time we make this change there).
🔗 No broken links found! ✅ Your attention to detail is admirable. linkcheck output
|
@microsoft-github-policy-service rerun |
## Description Bumps the (independent) test-tools package to the next major version. This is because we want to release 2.0 (with the changes from #23202) in order to fix the build of the LTS branch, and the first step towards that is bumping the package version in main to then cut the release branch from the commit before the bump is merged. Note: after this release, I'm hoping to make test-tools a private package inside the client release group (in #23211), so 2.x would be the last version we release for it. This bump would be just to satisfy the process to release it today.
Description
This updates the initial port that test-tools assigns to packages from 8081 to 9000 and makes it configurable.
Motivation
The build of the LTS branch is failing, and as far as I can tell it is due to a combination of two things:
assign-test-ports
executable from@fluidframework/test-tools
has jest tests so it tries to start jest in that port and fails.I imagine this started failing at some point when we made changes to the build infra, but since we're not continuously building the LTS branch, we didn't notice at the time. I even confirmed that running the build pipeline for the last commit in LTS for which it succeeded (May 2024), fails today.
The dependency update is purely opportunistic.
Reviewer Guidance
The review process is outlined on this wiki page.