1ESPT Schema Rollout

[priyatejankar]

No description provided.

[priyatejankar]

• This PR is created in order to be able to rollout 1ESPT schema to the customers.
• With this feature whenever a user is signed in to VS code with Microsoft account and they have 1ESPT available in their ADO org, they can enable the option to use Intellisense from 1ESPT schema while editing their yaml files.

• Whenever a user is not signed in to VS code, they will get a prompt to sign in in order to be able to use 1ESPT schema
  

• If the user has enabled 1ESPT Schema, it will take precedence over any other schemas

• A folder called '1ESPTSchema' is created to store the schemas. When user signs out this folder gets deleted

• If user signs out, we will default to behavior as before

• If user does not sign out of Visual Studio Code, their 1ESPT Schema file configuration will be stored

• If user signs out and signs back in, they will have to enable 1ESPT again

• While fetching schemas, we have a caching mechanism in place that remembers the last fetched schema.

• If the user has enabled 1ESPT schema, we will fetch the schema from the main branch if the last fetched schema is older than 24 hours

[flyingUnderTheRadar]

@50Wliu, @KonstantinTyukalov - please take a look and share feedback if any.

[winstliu]

In general this looks good! A few suggestions and questions, particularly about the config experience. At a high-level, I'd like to hear the rationale behind introducing a new config setting, rather than doing everything behind the scenes and "silently" upgrading them to 1ESPT if it's supported.

[priyatejankar]

@50Wliu Thanks for reviewing the PR :) I have addressed your comments. Please let me know if you have any other concerns.

[winstliu]

Just a few more comments! I'll want to give it a spin for myself to see what the config experience is like, but code-wise it's looking good :).

Ask: could you please go through and make sure all the lines you added:

• have semicolon endings
• use const/let, not var
• don't use any types

[winstliu]

1. On startup, I see the following error: Cannot read properties of undefined (reading 'name') at src\schema-association-service.ts:72:72. I would imagine this is because I don't have a workspace folder opened.
2. I'm really not a fan of persisting config changes without user input.
   • This creates unnecessary churn that will show up when going to commit changes
   • Whether they have access to 1ES Pipeline Templates is not controllable
   • If/when 1ESPT is added to their org, they need to remember to manually re-enable the setting. Knowing how to do this isn't obvious, because at a glance it'll look like the setting is already enabled (see picture below)
3. I would recommend changing the wording of the non-MS account message to use the 2nd-person (you vs user). In addition, "Microsoft account" here is ambiguous. I am signed in with a Microsoft account - my personal MSA. I would suggest finding a way to clarify that this is for Microsoft employees only.
4. Why do I get a message that the 1ESPT Schema is disabled even if I don't have the setting enabled in the first place? And why does it keep recreating a settings.json every time I try to remove it?

I am blocking on points 1, 3, and 4. Regarding point 2 specifically, I know we've already gone over this. I respect you and your team's stance and won't block this PR because we have different config philosophies, but to reduce friction and increase discoverability of this feature I would highly suggest:

1. Turning this feature on by default (even better would be removing the setting entirely)
2. Silently falling back to the other schemas if the prerequisites aren't met

This way anyone using this extension automatically gets the best intellisense available to them without needing to configure anything (other than signing in once).

[priyatejankar]

@50Wliu I have addressed your comments here. Please find my responses in bold:

1. On startup, I see the following error: Cannot read properties of undefined (reading 'name') at src\schema-association-service.ts:72:72. I would imagine this is because I don't have a workspace folder opened. -- This is same behavior as before and not something newly introduced

2. I'm really not a fan of persisting config changes without user input.**_

   • This creates unnecessary churn that will show up when going to commit changes
   • Whether they have access to 1ES Pipeline Templates is not controllable
   • If/when 1ESPT is added to their org, they need to remember to manually re-enable the setting. Knowing how to do this isn't obvious, because at a glance it'll look like the setting is already enabled (see picture below)
     -- We had an internal discussion and have decided to not change the value without user interaction. Even if the user is not eligible to use the feature and they enable it, we will keep it enabled. We have a text next to the feature option indicating the prerequisites for the feature to be enabled

3. I would recommend changing the wording of the non-MS account message to use the 2nd-person (you vs user). In addition, "Microsoft account" here is ambiguous. I am signed in with a Microsoft account - my personal MSA. I would suggest finding a way to clarify that this is for Microsoft employees only. -- Modified it to tell that feature is allowed for @microsoft.com user accounts only

4. Why do I get a message that the 1ESPT Schema is disabled even if I don't have the setting enabled in the first place? And why does it keep recreating a settings.json every time I try to remove it? -- Removed this message. Now, a message will be shown to enable the feature only after verifying that user has 1ESPT repo in their org. The settings.json gets updated when the value is changed. It is not getting recreated for me

I am blocking on points 1, 3, and 4. Regarding point 2 specifically, I know we've already gone over this. I respect you and your team's stance and won't block this PR because we have different config philosophies, but to reduce friction and increase discoverability of this feature I would highly suggest:

1. Turning this feature on by default (even better would be removing the setting entirely) -- We cannot enable this feature silently for all users as they might have 1ESPT in their ADO org but they are working on OneBranch pipelines
2. Silently falling back to the other schemas if the prerequisites aren't met

This way anyone using this extension automatically gets the best intellisense available to them without needing to configure anything (other than signing in once).

[winstliu]

Couple of small things

[winstliu]

Looking forward to seeing this in action! Should really help people using the 1ES templates :).