Skip to content

Conversation

@RReverser
Copy link
Contributor

Description of Changes

Before this, we couple of times ran into issues where a version in SpacetimeDB template was outdated, or NuGet sources were in incorrect order, and so on, which led to either tests failing with misleading error (2b09c8d being most recent example), or, worse, quietly passing even when code or versions are actually broken.

Apparently, NuGet has a package source mapping feature which allows to ensure that specific packages are only pulled from specific custom sources, which is exactly what we want here. It allows us to ensure that SpacetimeDB.* pacakges for smoketests are pulled from our local build folders, and not from nuget.org.

API and ABI breaking changes

If this is an API or ABI breaking change, please apply the
corresponding GitHub label.

Expected complexity level and risk

How complicated do you think these changes are? Grade on a scale from 1 to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex change.

This complexity rating applies not only to the complexity apparent in the diff,
but also to its interactions with existing and future code.

If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning ways.

Testing

Describe any testing you've done, and any testing you'd like your reviewers to do,
so that you're confident that all the changes work as expected!

  • Write a test you've completed here.
  • Write a test you want a reviewer to do here, so they can check it off when they're satisfied.

@RReverser RReverser marked this pull request as ready for review September 24, 2024 12:58
@RReverser RReverser requested review from bfops and jdetter September 24, 2024 12:58
@RReverser
Copy link
Contributor Author

Awesome, looks like this currently catches an issue that will be fixed by #1734.

RReverser added a commit to clockworklabs/com.clockworklabs.spacetimedbsdk that referenced this pull request Sep 24, 2024
@RReverser RReverser force-pushed the ingvar/csharp-smoketest-stricter-nuget-config branch from 50f971c to 84201f3 Compare September 24, 2024 15:04
Copy link
Contributor

@mamcx mamcx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

<packageSource key="Local SpacetimeDB.BSATN.Runtime">
<package pattern="SpacetimeDB.BSATN.Runtime" />
</packageSource>
</packageSourceMapping>
Copy link
Collaborator

@bfops bfops Sep 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, the previous nuget-fallback behavior was entirely intentional (see the PR description that introduced it: #1503).

tl;dr it was set up so that, when we released breaking changes in this repo, the SDK tests would continue to use a package they were compatible with, rather than breaking for every future SpacetimeDB PR until someone fixed the C# SDK.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This way, the C# SDK tests only break if you fail to bump the version numbers when you make a breaking change.

I don't feel strongly about keeping it that way (and I believe it's not a required check, so this doesn't "deadlock" us), but that was the original intent.

Copy link
Contributor Author

@RReverser RReverser Sep 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This way, the C# SDK tests only break if you fail to bump the version numbers when you make a breaking change.

Problem is, we also have the opposite sometimes - we bumped SpacetimeDB version, made some breaking changes, but C# SDK tests are still passing "successfully" because they are still pointing to old BSATN.* packages.

This is too easy to miss at the moment, so I do think the noisy error would be better in this context as it would allow us to catch issues sooner rather than later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I can see the arguments for the original behaviour too...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good - we should probably add a requirement that people breaking a downstream repo (in this case, the C# SDK) have a fix PR ready to go before merging their breaking change in this repo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say let's try this stricter mode to catch breaking behaviour sooner; if it does prove too annoying, we can always revert those changes.

@RReverser RReverser enabled auto-merge September 27, 2024 22:43
Before this, we couple of times ran into issues where a version in SpacetimeDB template was outdated, or NuGet sources were in incorrect order, and so on, which led to either tests failing with misleading error (2b09c8d being most recent example), or, worse, quietly passing even when code or versions are actually broken.

Apparently, NuGet has a package source mapping feature which allows to ensure that specific packages are only pulled from specific custom sources, which is exactly what we want here. It allows us to ensure that SpacetimeDB.* pacakges for smoketests are pulled from our local build folders, and not from nuget.org.
@RReverser RReverser force-pushed the ingvar/csharp-smoketest-stricter-nuget-config branch from 84201f3 to 71e900e Compare September 28, 2024 01:45
@RReverser RReverser added this pull request to the merge queue Sep 28, 2024
Merged via the queue into master with commit 075efb6 Sep 28, 2024
7 checks passed
@RReverser RReverser deleted the ingvar/csharp-smoketest-stricter-nuget-config branch September 28, 2024 18:59
RReverser added a commit to clockworklabs/com.clockworklabs.spacetimedbsdk that referenced this pull request Oct 2, 2024
## Description of Changes

Same as clockworklabs/SpacetimeDB#1735 but for
this repo.

## API

 - [ ] This is an API breaking change to the SDK

*If the API is breaking, please state below what will break*


## Requires SpacetimeDB PRs
*List any PRs here that are required for this SDK change to work*
bfops pushed a commit that referenced this pull request Jul 17, 2025
## Description of Changes

Same as #1735 but for
this repo.

## API

 - [ ] This is an API breaking change to the SDK

*If the API is breaking, please state below what will break*


## Requires SpacetimeDB PRs
*List any PRs here that are required for this SDK change to work*
bfops pushed a commit to clockworklabs/com.clockworklabs.spacetimedbsdk that referenced this pull request Jul 28, 2025
## Description of Changes

Same as clockworklabs/SpacetimeDB#1735 but for
this repo.

## API

 - [ ] This is an API breaking change to the SDK

*If the API is breaking, please state below what will break*


## Requires SpacetimeDB PRs
*List any PRs here that are required for this SDK change to work*
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.

4 participants