-
Notifications
You must be signed in to change notification settings - Fork 2.1k
create-turbo: improve test cases and make them pass #1655
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
Conversation
@mehulkar is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
d7addd8
to
fc0b6b8
Compare
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.
600dc50
to
6331015
Compare
os: [ | ||
ubuntu-latest, | ||
macos-latest, | ||
# windows-latest, |
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 like to come back to this
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.
A comment detailing what issues were encountered would be helpful
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.
It didn't seem to pass in CI and I wanted to isolate the issue and fix. I'm not even sure at this point it's a real problem
8881c8a
to
370d010
Compare
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
outdated! needs another look now
@@ -0,0 +1,78 @@ | |||
name: CI JS |
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.
Is this 100% a copy of ci-go
with the npm section and the create-turbo
tests added?
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.
pretty much, but excludes the examples
action (terminology?) and excludes the Go tests
os: [ | ||
ubuntu-latest, | ||
macos-latest, | ||
# windows-latest, |
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 tried to track down previous runs, got a link? (Don't mind tabling, but I do want to see it.)
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.
https://github.com/vercel/turborepo/runs/7777949925?check_suite_focus=true
I tthink the issue is that yarn -v
is erroring or the npm i -g yarn
isn't working. Something for a followup PR
@@ -23,6 +23,8 @@ const DEFAULT_JEST_TIMEOUT = 10000; | |||
|
|||
describe("create-turbo cli", () => { | |||
beforeAll(() => { | |||
execSync("corepack disable", { stdio: "ignore" }); |
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.
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 think so. We could also just not install corepack
in ci-js.yml
, but I did it anyway so CI matches what we'll have on dev machines.
Although if/when that issue is resolved, we might still want this so we can represent a real npx
usecase where a packageManager (or its shim) isn't available and we really do want to show the "not available" case. I don't have a foolproof way forward to address both cases
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.
(That link was mostly to get a pointer to this discussion upstream.)
- name: Setup Yarn | ||
run: npm i -g yarn |
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.
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.
One comment about an extra test case, but otherwise looks good
); | ||
|
||
expect(messages[2]).toMatch( | ||
/^>>> Creating a new turborepo with the following:/ |
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.
Can we add a check for:
>>> Success! Created a new Turborepo at "${DEFAULT_APP_NAME}".
as well? This would catch that pnpm
error we had a few weeks ago (the install actually worked, pnpm was just non-zero exiting because it was upset about peers. (which caused us to not show this message and show install has failed
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 can add that, but I wasn't able to reproduce that failure, for what it's worth :/
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.
after this PR when tests are running in CI, we can have a bit more confidence about adding new tests if we have regressions again.
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'll defer to @nathanhammond for final LGTM since I think I'm a little out of the loop on the context here.
In general, this looks fine to me. Just getting these running seems like a step in the right direction. Some things we might want to consider adding, now or in the future
- displaying the versions of the package managers used, if possible. if an upgrade breaks something, that will help us know
- are we going to test old and new yarn ("berry")?
Good ideas. I think it makes sense to get these running first and add more as needed
I'd have to think about how to make this possible, since the CI setup (rather than the test case itself) is installing and activating the yarn/npm/etc. |
Test failure? Or is it flaky? |
I think they are flaky. Looks like it's the Go e2e ones, which shouldn't be affected by this PR.
|
- Make existing tests pass - Add GH action to run tests in CI Set up a new Github Action that builds the turbo CLI (since that is required for the create-turbo tests) and runs the JS tests for that package. Notable things: - Installs yarn and disables corepack as part of the test suite. This is the pristine state we want for the tests that exist today. For future tests cases that have a different setup, we may need to modify this more. - Disables Windows tests. This yarn setup on Windows does not seem to work, but this gets us one step forward.
Make existing tests pass
Add GH action to run tests in CI
Set up a new Github Action that builds the turbo CLI (since that is
required for the create-turbo tests) and runs the JS tests for that
package.
Notable things:
Installs yarn and disables corepack as part of the test suite. This
is the pristine state we want for the tests that exist today. For
future tests cases that have a different setup, we may need to
modify this more.
Disables Windows tests. This yarn setup on Windows does not seem to
work, but this gets us one step forward.