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.

Sign up for GitHub

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

Jump to bottom

Updating identity v2 beta versions for identity tests and reverting to GA version v1 for samples #15654

Merged
merged 10 commits into from
Jun 11, 2021
Merged

Updating identity v2 beta versions for identity tests and reverting to GA version v1 for samples #15654

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
9e5fd4b
samples identity
KarishmaGhiya Jun 9, 2021
778d80b
update identity version
KarishmaGhiya Jun 10, 2021
f1140d8
update version
KarishmaGhiya Jun 10, 2021
09c4904
update identity versions for internal tests
KarishmaGhiya Jun 10, 2021
dc3a500
format
KarishmaGhiya Jun 11, 2021
cf76d8f
fix the dependecyOverrides
KarishmaGhiya Jun 11, 2021
ee6f131
replace tenant id
KarishmaGhiya Jun 11, 2021
a1bb3d7
update identity to beta.4
KarishmaGhiya Jun 11, 2021
dc267e6
Update node recordings
jeremymeng Jun 11, 2021
5f75241
re-gen nodejs recordings
jeremymeng Jun 11, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
samples identity
  • Loading branch information
@KarishmaGhiya
KarishmaGhiya committed Jun 10, 2021
commit 9e5fd4bf0111bde301d84fda53ccd0191d0e6c21
16 changes: 8 additions & 8 deletions common/config/rush/pnpm-lock.yaml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion sdk/containerregistry/container-registry/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,7 +87,7 @@
"devDependencies": {
"@azure/dev-tool": "^1.0.0",
"@azure/eslint-plugin-azure-sdk": "^3.0.0",
"@azure/identity": "^1.1.0",
"@azure/identity": "2.0.0-beta.3",
Copy link
Member

Choose a reason for hiding this comment

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

same question about beta3 vs beta4.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

"@azure/ms-rest-nodeauth": "^3.0.8",
"@azure/test-utils-recorder": "^1.0.0",
"@microsoft/api-extractor": "7.7.11",
Expand Down
2 changes: 1 addition & 1 deletion sdk/containerregistry/container-registry/samples/v1/javascript/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,6 @@
"dependencies": {
"@azure/container-registry": "next",
"dotenv": "latest",
"@azure/identity": "^1.1.0"
"@azure/identity": "2.0.0-beta.3"
Copy link
Member

Choose a reason for hiding this comment

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

I think this will be overwritten next time the publish command is run. I think this change should happen in dev-tool or specified in package.json's sampleConfiguration entry:

"//sampleConfiguration": {
    // Any dependency version specifications in this setting will be preferred
    // over the dependencies specified in your ordinary dependencies or
    // devDependencies.
    "dependencyOverrides": {
      // For example, this setting will cause the generated sample packages
      // to include a dependency on a beta version of identity instead of the
      // version that your package depends on (currently ^1.1.0)
      "@azure/identity": "2.0.0-beta.3"
    }
  }

cc @witemple-msft

Copy link
Member

Choose a reason for hiding this comment

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

or maybe I am wrong. @witemple-msft does the versions in the samples' package.json come from the package's package.json?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd thought the sample's dependencies would be computed from the main package.json, no?

Copy link
Member

Choose a reason for hiding this comment

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

I think you're right, ignore my request then unless Will says otherwise.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@deyaaeldeen I think the "dependencyOverride" setting in the main package's package.json is when we want to specify an exception for the samples - in this case if we want samples to depend on a version of identity other than the package's dependency, then we'll use that setting.

}
}
2 changes: 1 addition & 1 deletion sdk/containerregistry/container-registry/samples/v1/typescript/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@
"dependencies": {
"@azure/container-registry": "next",
"dotenv": "latest",
"@azure/identity": "^1.1.0"
"@azure/identity": "2.0.0-beta.3"
},
"devDependencies": {
"typescript": "~4.2.0",
Expand Down
2 changes: 1 addition & 1 deletion sdk/eventhub/event-hubs/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,7 +106,7 @@
"devDependencies": {
"@azure/dev-tool": "^1.0.0",
"@azure/eslint-plugin-azure-sdk": "^3.0.0",
"@azure/identity": "^1.1.0",
"@azure/identity": "2.0.0-beta.3",
Copy link
Contributor

Choose a reason for hiding this comment

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

Wait, why does event hubs get beta.3 and everyone else gets beta.4? I feel left behind 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now it should be on par with everyone 🥇

Copy link
Member

Choose a reason for hiding this comment

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

is this intentionally beta.3 vs beta.4?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No I was in the middle of conversation with Daniel when I made this beta.3, then we decided to go with beta.4. Thanks!

"@azure/test-utils-perfstress": "^1.0.0",
"@microsoft/api-extractor": "7.7.11",
"@rollup/plugin-commonjs": "11.0.2",
Expand Down
2 changes: 1 addition & 1 deletion sdk/eventhub/event-hubs/samples/browserSample/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@
"sideEffects": false,
"dependencies": {
"@azure/event-hubs": "^5.0.0",
"@azure/identity": "^1.0.2"
"@azure/identity": "2.0.0-beta.3"
Copy link
Member

Choose a reason for hiding this comment

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

Is the Identity GA for 2.x happening soon? I'm wondering why we're updating samples if we don't want users to bake a beta into their programs (ie, if they're using this as an example of what they have to reference).

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 think that's a good point. @sadasant Why do we want to update samples' identity dependency?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also in some of the packages, the dependency for the samples is mentioned as a dev-dep in the package. So in making that transition, there might be situation where samples depend on an identity version other than the version that package takes dev dep on. Thoughts? @sadasant

Copy link
Contributor

Choose a reason for hiding this comment

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

We want to make sure that as many things that use Identity get to use v2 before we release it. v2 will release on September

Copy link
Contributor

Choose a reason for hiding this comment

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

anything that runs on CI will potentially help us catch bugs before we release 🙏

Copy link
Contributor

Choose a reason for hiding this comment

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

For what it's worth, the browser sample is not run on CI. I also am hesitant to depend on a beta in a sample.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is it ok to use beta for node samples, since those run in ci? @chradek

Copy link
Contributor

Choose a reason for hiding this comment

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

Our tests should be using the v2-beta of Identity to help with getting test coverage. Samples is for the end customers to use and should not use beta versions. Also, if we are getting some test coverage in samples that we are not getting in our tests, then we should take another look at our tests.

Copy link
Member

@xirzec xirzec Jun 10, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

I think the only samples that should use the beta would be samples that require said beta? If this sample works against the GA version of identity, I would think it should target the GA version of identity.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is it ok to use beta for node samples, since those run in ci?

I'll echo @ramya-rao-a and @xirzec that I don't think samples should use betas unless they need functionality that's only in the beta.

These show up in our published documentation for GA packages, so having a user start by using one of our samples that depends on a beta can lead to a poor experience. We haven't been shy about making breaking changes in between beta versions so I'd hate for a customer to end up depending on something still going through churn because they downloaded an official sample.

},
"devDependencies": {
"http-server": "^0.12.1",
Expand Down