Skip to content
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

Merged
merged 30 commits into from
Nov 16, 2022

Conversation

tylerbutler
Copy link
Member

@tylerbutler tylerbutler commented Nov 8, 2022

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 as
minor version series branches, while the next branch is designated for major releases.

"fluidBuild": {
  "branchReleaseTypes": {
    "main": "minor",
    "lts": "minor",
    "release/**": "patch",
    "next": "major"
  }
}

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:

Branch release designation Baseline version Example: version 2.3.4
patch previousPatch 2.3.3
minor ^previousMinor ^2.2.0
major ^previousMajor ^1.0.0

BREAKING CHANGE: fluid-type-validator is deprecated. Use flub generate typetests instead.

@github-actions github-actions bot added public api change Changes to a public API base: main PRs targeted against main branch labels Nov 8, 2022
@msfluid-bot
Copy link
Collaborator

msfluid-bot commented Nov 11, 2022

Baseline CI build failed, cannot generate bundle analysis at this time


Baseline commit: c5f89d0

Generated by 🚫 dangerJS against 5660bd2

@tylerbutler tylerbutler marked this pull request as ready for review November 11, 2022 23:14
@tylerbutler tylerbutler requested review from msfluid-bot and a team as code owners November 11, 2022 23:14
Copy link
Contributor

@Josmithr Josmithr left a 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
Copy link
Contributor

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.

Copy link
Member Author

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",
Copy link
Contributor

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?

Copy link
Member Author

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/common/fluidRepo.ts Outdated Show resolved Hide resolved
package.json Outdated
@@ -177,6 +190,7 @@
]
},
"additionalLockfilePaths": [
"azure",
"common/build/build-common",
Copy link
Contributor

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?

Copy link
Member Author

Choose a reason for hiding this comment

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

See #12726.

Copy link
Member Author

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.

Copy link
Member Author

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.

build-tools/packages/build-cli/docs/generate.md Outdated Show resolved Hide resolved
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": {
Copy link

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.

Copy link
Member Author

@tylerbutler tylerbutler Nov 15, 2022

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`
Copy link

@ssimic2 ssimic2 Nov 15, 2022

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 :)

Copy link
Member Author

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]
Copy link

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." ?

Copy link
Member Author

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.

@tylerbutler tylerbutler changed the title feat(generate:typetests): Make type tests configurable per-branch feat!(generate:typetests): Make type tests configurable per-branch Nov 16, 2022
@tylerbutler tylerbutler changed the title feat!(generate:typetests): Make type tests configurable per-branch feat(generate:typetests)!: Make type tests configurable per-branch Nov 16, 2022
@tylerbutler tylerbutler merged commit 8c29adc into microsoft:main Nov 16, 2022
@tylerbutler tylerbutler deleted the cli/typetest-branch-config branch November 16, 2022 21:24
tylerbutler added a commit that referenced this pull request Nov 16, 2022
This dependency was missed when some code was moved in PR #12849. It
wasn't found due to lerna's hoisting behavior.
tylerbutler added a commit that referenced this pull request Nov 22, 2022
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
base: main PRs targeted against main branch public api change Changes to a public API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants