Skip to content
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

deps: upgrade to latest prisma & fix tests #85

Merged
merged 13 commits into from
Jun 21, 2021
Merged

deps: upgrade to latest prisma & fix tests #85

merged 13 commits into from
Jun 21, 2021

Conversation

jasonkuhrt
Copy link
Member

@jasonkuhrt jasonkuhrt commented Jun 21, 2021

closes #78

@codecov-commenter
Copy link

codecov-commenter commented Jun 21, 2021

Codecov Report

Merging #85 (3db027a) into main (7d1c18d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #85   +/-   ##
=======================================
  Coverage   44.82%   44.82%           
=======================================
  Files          26       26           
  Lines         406      406           
  Branches       80       80           
=======================================
  Hits          182      182           
  Misses        205      205           
  Partials       19       19           

@jasonkuhrt
Copy link
Member Author

@janpio @Jolg42 It used to be that this worked. The prisma client was specified to be output at ./client or something. After a Prisma upgrade 2704ff2 to 2.24 tests began to break.

  execa.commandSync(`yarn -s prisma db push --force-reset --schema ${dir}/schema.prisma`)

I fixed this once using Jest runInBand. The commit above. That tells me that two Jest test suites were conflicting. And indeed the test error output indicates snapshots failing with results from one another.

Having to use runInBand is a hack, not ideal etc. It is also not a big deal. The worst of it is using it when not knowing why, as is the case now.

I am going to try to change execa (shown above) to run so that it is actually spawning the child process IN the dir, rather than given a path to the schema in the dir. I am betting that will get things working again, how they used to, without runInBand.

@jasonkuhrt
Copy link
Member Author

@Jolg42 maybe the issue was how prisma schema output relative paths were resolved? I have been doing output = './client' so far.

@jasonkuhrt
Copy link
Member Author

jasonkuhrt commented Jun 21, 2021

My solution worked I think, but the relative path stuff isn't working on Windows. https://github.com/prisma/nexus-prisma/pull/85/checks?check_run_id=2879192617 I thought it might not. Will try relative path another way. But first will try absolute output config.

@jasonkuhrt
Copy link
Member Author

I have no idea what is going on, the macos tests pass on everything but then hang on trying to run the next integration test.

When I run in band, there is no issue.

On my machine, there is no issue.

:(

Well, I did my best, here comes runInBand at least for now.

@jasonkuhrt jasonkuhrt changed the title deps: upgrade to latest prisma deps: upgrade to latest prisma & fix tests Jun 21, 2021
@jasonkuhrt jasonkuhrt merged commit aad2e2f into main Jun 21, 2021
@jasonkuhrt jasonkuhrt deleted the tests/fix branch June 21, 2021 22:19
@Jolg42
Copy link
Contributor

Jolg42 commented Jun 22, 2021

Might be related to @millsp PR I think

Probably fixed with prisma/prisma#7797?

@rostislav-simonik-nexus-prisma-admin
Copy link
Collaborator

🎉 This PR is included in version 1.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix tests
4 participants