ci: Run CI with specific Parse Server versions

[mtrezza]

No description provided.

[parse-github-assistant]

🚀 Thanks for opening this pull request!

[dplewis]

@mtrezza Doesn't #2557 fix this build issue? Can you update from alpha?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (cfb25ef) to head (c9c63ee).

Additional details and impacted files

@@            Coverage Diff            @@
##             alpha     #2539   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           64        64           
  Lines         6238      6238           
  Branches      1465      1465           
=========================================
  Hits          6238      6238           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mtrezza]

This is a different thing. It's an attempt (wip) to change the CI to install a specific version of Parse Server, then install the current JS SDK in Parse Server and then run the full Parse Server tests. It's to ensure that a change in the JS SDK won't break a Parse Sever test.

As a first step this should only run the SDK tests with different PS versions, but that fails.

[dplewis]

I'd rather keep the current way of release the SDK then open a PR on the server and see if it breaks. What happens if the Parse Server test suite does break? We can't update the Parse Server tests as the SDK hasn't been released yet. Not to mention adding 10+ minutes of ci time.

Keep the current changes in this PR and add something like it_only_parse_server_version to fix CI. The compatibility table also needs updating.

[mtrezza]

I'd rather keep the current way of release the SDK then open a PR on the server and see if it breaks. What happens if the Parse Server test suite does break? We can't update the Parse Server tests as the SDK hasn't been released yet.

Sure, this is just meant to detect issues in the SDK, not on the server side. The challenge is that we should detect an issue before making a stable release, because then the bug can affect developers. We don't test with alpha releases of the SDK, so we are releasing an SDK that has not been fully tested with Parse Server.

I believe this goes back to parse-community/parse-server#8787, which gives us 2 uses cases:

• a) SDK used as client -- the SDK tests should detect any issues; we still do a lot of mocking here, but we have integration tests, so that works for now.
• b) SDK used as Parse Server dependency -- the SDK release must work internally with Parse Server, so the SDK CI should ensure this before merging a PR

I'd like to cover (b), which is currently not covered.

Another, unrelated issue is to run the SDK CI with multiple versions of Parse Server, which is the current change in this PR.

[dplewis]

The challenge is that we should detect an issue before making a stable release, because then the bug can affect developers.

Which bugs are you talking about? It's not like installing the SDK along side Parse Server will override the SDK internally used on the server.

Besides Parse.Error, Parse._encode, Parse._decode what else does Parse Server use internally that could potentially break it?

[mtrezza]

Besides Parse.Error, Parse._encode, Parse._decode what else does Parse Server use internally that could potentially break it?

Well, for example these. I'm fine with leaving as is, but I'm afraid it will take a long time until parse-community/parse-server#8787 get's done.

This PR instead could focus on what you mentioned and add it_only_parse_server_version, so just run the SDK against different version of Parse Server. Not sure why the CI doesn't pass, need to look into that.

[dplewis]

Well, for example these.

Those haven't changed in years and probably won't change.

but I'm afraid it will take a long time until parse-community/parse-server#8787 get's done.

Let's start by moving all internal uses of the SDK on Parse Server to a single file so we can see what exactly is used. Then we can decide if we want to use it as a devDependency or dependency. For example Parse._encode is only used for Dates and Cloud Code responses. We don't need the SDK to encode dates. Edit: I see you already updated parse-community/parse-server#8787

Not sure why the CI doesn't pass, need to look into that.

Default ACL was added in v8 so it's different from v7