-
Notifications
You must be signed in to change notification settings - Fork 536
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
feat(generate:typetests)!: Make type tests configurable per-branch #12849
feat(generate:typetests)!: Make type tests configurable per-branch #12849
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One high-level thing I think would be worth some docs on in the overview doc is what to do when resolving conflicts when merging branches. E.g. what do I do if I'm merging main into next and get type-test / type-test config conflicts?
Generating type tests has two parts: _preparing package.json_ and _generating test modules_. By default, both steps are | ||
run for each package. You can run only one part at a time using the `--prepare` and `--generate` flags. | ||
|
||
[api type validation]: https://github.com/microsoft/FluidFramework/wiki/API-Type-Validation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious on your thoughts WRT conventions for where to put link aliases. I find it useful to be able to look in a single place in a given document for the links so I know what things I can re-use and what I need to define as I go.
Would it make sense to move this to the bottom under a "links" comment like we generate for content on the website?
Feel free to disregard in the context of the PR - it just took me a few seconds to find where this was defined as I was reviewing, since I wanted to make sure it was defined somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I usually put them at the end of the section in which they're used unless they're used in several places. Reason being that sections get moved/reorganized, and links sometimes break when they're far away from the content. But I don't care too much.
@@ -59,10 +64,11 @@ export default class GenerateTypeTestsCommand extends BaseCommand< | |||
"~previousMinor", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we generate this list from the PreviousVersionStyle
type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a union type, so no, not as far as I know.
build-tools/packages/build-tools/src/typeValidator/packageJson.ts
Outdated
Show resolved
Hide resolved
package.json
Outdated
@@ -177,6 +190,7 @@ | |||
] | |||
}, | |||
"additionalLockfilePaths": [ | |||
"azure", | |||
"common/build/build-common", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Not for this PR) do the packages under common/lib
need to be added here? For my knowledge, what is this field used for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #12726.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The azure entry shouldn't be needed. I'll investigate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems related to switching the azure release group from a "simple" config to a "complex" one (an object instead of a string). I'm going to ignore for this PR since there's a clear workaround (adding the entry here) and follow up with another change later.
package.json
Outdated
@@ -138,12 +138,25 @@ | |||
"common-def": "common/lib/common-definitions", | |||
"common-utils": "common/lib/common-utils", | |||
"protocol-def": "common/lib/protocol-definitions", | |||
"azure": "azure", | |||
"azure": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems somewhat odd that we would define this here, and not in "azure" directory since it is its own Monorepo. I understand that root package.json can manage config across all monorepos (not just client), but when developing around azure-client I do spend most of the time in azure folder, (likely wrongly) assuming that its fully self contained.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Josmithr had the same feedback. I'll explore configuring release groups in their root this morning.
It may be useful to configure a branch for a specific baseline instead of the default based on the branch release | ||
designation. To do this, you can use any of the following strings instead of major/minor/patch. | ||
|
||
- `baseMajor` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe some super-short description here on "base" would be helpful. When I think of "previous" I think about previous to existing branch version, but "base" I cannot fit into my mental model, or at least I assume we don't want to run compat tests against self :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarified both here and in the tsdocs:
The "base" versions are calculated by zeroing out all version segments lower than the base. That is, for a version v,
the baseMajor version is ${v.major}.0.0
and the baseMinor version is ${v.major}.${v.minor}.0
.
The "previous" versions work similarly, but the major/minor/patch segment is reduced by 1. That is, for a version v,
the previousMajor version is ${min(v.major - 1, 1)}.0.0
, the previousMinor version is
${v.major}.${min(v.minor - 1, 0)}.0
, and the previousPatch is ${v.major}.${v.minor}.${min(v.patch - 1, 0)}.0
.
The "previous" versions never roll back below 1 for the major version and 0 for minor and patch. That is, the
previousMajor, previousMinor, and previousPatch versions for 1.0.0
are all 1.0.0
.
@@ -114,18 +114,17 @@ Generates type tests based on the individual package settings in package.json. | |||
``` | |||
USAGE | |||
$ flub generate typetests [-d <value> | --packages | -g client|server|azure|build-tools] [--prepare | --generate] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you clarify --packages: "Run on all independent packages in the repo." ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a shortcut to run generation on all independent packages, like build-common, common-utils, etc. The alternative is to use the --dir
option and pass the path to the package, but this is more convenient when you're updating them all. Clarified in the flag docs.
This dependency was missed when some code was moved in PR #12849. It wasn't found due to lerna's hoisting behavior.
I manually updated the npm scripts to call flub with the correct arguments etc. Relevant changes: - Uses the `--pin` argument to pin the version in package.json to the maximum matching released version. This should help with the lockfile issues we have discovered. - All generated files now include `.generated` in their name and old files were deleted. This was detected as a rename by git. See #12849 or `typetestDetails.md` for documentation on semantics of these changes. Then I did the following steps to configure the baselines and generate tests. 1. `npm run typetests:prepare -- -b main --reset` - this reset all type test overrides and set the baseline versions according to the main branch config. For the client release group this is `~previousMinor`, which corresponds to version 2.0.0-internal.2.1.0. 2. `npm i` - installed new versions of packages. 3. `npm run typetests:gen -- -b main` - this regenerated the typetests. 4. Ran a build and added back broken test overrides as needed. 5. Disabled tests in some packages like PropertyDDS. I also did roughly the same steps for the independent packages.
Type tests can now be configured to use different baseline versions on a given branch depending on the type of release that
the branch is designated for. For example, for the client release group, the next branch is the major version series
branch and main is the minor version series branch. This can be declared in the release group root package.json, in the
fluidBuild.branchReleaseTypes
section. For example, the following configuration designates the main and lts branches asminor version series branches, while the next branch is designated for major releases.
The type test generator takes this information into account when calculating the baseline version to use when it's run
from a particular branch. Baseline versions are set as follows based on the branch release designation:
previousPatch
^previousMinor
^previousMajor
BREAKING CHANGE:
fluid-type-validator
is deprecated. Useflub generate typetests
instead.