Skip to content

Conversation

@jfeingold35
Copy link
Contributor

What does this PR do?

Adds support for the new RunRelevantTests test level, and validation to ensure that this option is only available in API version 66.0 or later.

What issues does this PR fix or reference?

@W-20152151@

Functionality Before

The only TestLevel options were NoTests, RunLocalTests, RunAllTestsInOrg and RunSpecifiedTests.

Functionality After

A new RunRelevantTests option is available.

@jfeingold35 jfeingold35 requested a review from a team as a code owner November 7, 2025 19:54
"mime": "2.6.0",
"minimatch": "^9.0.5",
"proxy-agent": "^6.4.0",
"semver": "^7.7.3",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

semver is a library I've used in other places (e.g., Code Analyzer) to do semantic version comparison.


# error_invalid_test_level

TestLevel cannot be '%s' unless API version is %s or 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.

I imagine this message needs to go through some kind of review from a tech writer?

public constructor(options: MetadataApiDeployOptions) {
super(options);
options.apiOptions = { ...MetadataApiDeploy.DEFAULT_OPTIONS.apiOptions, ...options.apiOptions };
validateOptions(options);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ordinarily, I dislike putting errors in a constructor, but doing it here lets us fail faster at the immediate point of invalidity instead of waiting to do it somewhere else.

apiOptions: {
testLevel: 'RunRelevantTests',
},
apiVersion: '8.0', // Tricksy case here: 8.0 is alphabetically after "66.0" but semantically after it.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

mocha doesn't have it.each(), so it's harder to write parameterized tests. I chose to have the tricksiest case be the one I wrote. I'm fine manually adding others if we want. (Sidebar: Do we plan to stay on Mocha indefinitely, or is there a plan to migrate this repo to something like vitest or jest?)

return fileResponses;
};

const validateOptions = (options: MetadataApiDeployOptions): void => {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tried to keep this method open-ended so we can expand on it in the future as needed.
Question: is there a reason for the const x = () => {} instead of function x() {} syntax?

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.

3 participants