Skip to content
This repository was archived by the owner on Feb 6, 2026. It is now read-only.

Fix SDF API tests and Re-enable queueing the Edda Task for Deployment MVs on Migration#7552

Merged
jobelenus merged 2 commits intomainfrom
brit/sdf-api-tests-cant-rely-on-schema-variant-categories-mv
Oct 19, 2025
Merged

Fix SDF API tests and Re-enable queueing the Edda Task for Deployment MVs on Migration#7552
jobelenus merged 2 commits intomainfrom
brit/sdf-api-tests-cant-rely-on-schema-variant-categories-mv

Conversation

@britmyerss
Copy link
Contributor

How does this PR change the system?

With the removal of the SchemaVariantCategories MV, these tests need to be updated to not rely on them. We were previously using this MV to determine whether various Schemas used in tests were installed or not, as SDF still requires the caller to pass in this information.

The following updates were made:

  • Add support for fetching the deployment index and deployment MVs from SDF
  • Create a test helper that creates the correct component payload, based on whether the schema in question is installed or not
  • Update all tests to use the new helper
  • Update 8-check_mjolnir, which was directly relying on SchemaVariantCategories to determine that a variant was installed when the component was created for it. Replace this with checking for the LuminorkDefaultVariant
  • Update 2-create_and_apply_across_change_sets to hardcode the SchemaId for the TestResourceActions Schema, which is a special asset we use only for that test that exists in the module index

Bonus:
We had disabled enqueuing the Edda task that would build the Deployment MVs, when the builtins are cached during migration as the task was taking 4ish hours. Now that this task completes rather quickly, let’s do this on migration again. This mostly improves the local dev experience so we don’t have to manually enqueue it to see the builtins available for component creation on startup.

Out of Scope:

We should really update SDF and Web to work like Luminork when creating new components. A job for another day.

How was it tested?

All tests pass locally, including various permutations of having variants installed or not.

In short: 🔗

…ories

With the removal of SchemaVariantCategories, these tests need to be updated to not rely on them.  We were previously using this MV to determine whether various Schemas used in tests were installed or not, as SDF still requires the caller to pass in this information.  

The following updates were made: 
- Add support for fetching the deployment index and deployment MVs
- Create a test helper that creates the correct component payload, based on whether the schema in question is installed or not
- Update all tests to use the new helper
- Update 8-check_mjolnir, which was directly relying on SchemaVariantCategories to determine that a variant was installed when the component was created for it. Replace this with checking for the LuminorkDefaultVariant 
- Update 2-create_and_apply_across_change_sets to hardcode the `SchemaId` for the `TestResourceActions` Schema, which is a special asset we use only for that test that exists in the module index
We had disabled enqueuing the Edda task that would build the Deployment MVs, when the builtins are cached during migration as the task was taking 4ish hours. Now that this task completes rather quickly, let’s do this on migration again. This mostly improves the local dev experience so we don’t have to manually enqueue it to see the builtins available for component creation on startup.
@github-actions
Copy link

Dependency Review

✅ No vulnerabilities or OpenSSF Scorecard issues found.

Scanned Files

None

@britmyerss
Copy link
Contributor Author

Successful run here in tools: https://github.com/systeminit/si/actions/runs/18625982473

@jobelenus jobelenus added this pull request to the merge queue Oct 19, 2025
Merged via the queue into main with commit 0279be1 Oct 19, 2025
22 checks passed
@jobelenus jobelenus deleted the brit/sdf-api-tests-cant-rely-on-schema-variant-categories-mv branch October 19, 2025 15:31
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants