microsoft / azure-pipelines-vscode Goto Github PK

Connections are dynamically added per account. When selecting one in YAML, show the user autocomplete with their specific connections loaded from the server.

The intelisense doesn't seem to be functioning when a file has not yet been saved

• Create a new file (Control N for example)
• Switch the language mode to Azure Pipelines

• Press control space
• No suggestions popup is shown

Workaround:

• save the file as dummy.yaml (it will be recognized as a yaml file)
• switch the type to azure pipelines in Select Language Mode filter)

intelissense now works

The Docker@1 task has an incorrect enum. It's using the long name of each option, not the actual command. I suspect (without looking) that all enum generation is broken this way.

Would be nice to have the agent.*, build.*, and system.* series as suggestions in appropriate places.

To work around bugs in the language server, the schema currently allows both 'jobs' and 'steps' at the root. These should be mutually exclusive.

Phase names are optional. This shouldn't flag an error:

Caused lost intellisense at least for task name when added. Previous schema:

"templateConditionalStepInsertExpression": {
"type": "object",
"patternProperties": {
"^\${{.*}}$": {
"type": "array",
"items": {
"$ref": "#/definitions/step"
}
}
},
"minProperties": 1,
"maxProperties": 1
}

We can add uniqueItems constraints on arrays such as variables. May need to get a bit more crafty on phases, since it's an object property that has to be unique.

For common tasks, offer a quick way to insert the task and its most common inputs.

Use App Insights or some other built in mechanism to see extension install counts.

https://medium.com/@almenon214/adding-telemetry-to-your-vscode-extension-f3d52d2e573c

Pipeline on the left, plain YAML on the right.

We need to support multiple schemas. For instance, when YAML ships in on-prem, that version will be locked, but the service will continue to iterate. We'll need to package a snapshot of each static schema into the extension. (There's only one right now, the service.)

When a workspace has no associated schema, prefer the latest. Give the user a gesture, such as a command in the command palette, to change the association. (To investigate: can we inject a menu in the bottom status bar, alongside the language ID/line endings/encoding menus?)

One of the options - likely the most common - will be a schema from the server/service. The user can specify the Azure DevOps organization (or, eventually, the Azure DevOps Server instance) to use, log into it (using Azure Account if we can), and we'll grab the schema from a known endpoint. This will include the latest core schema, all custom tasks, etc.

We should cache what we retrieve from the server. We'll need to identify a cadence for refreshing it, since it does change periodically. I propose no more often than once a day, with a gesture to go pull a fresh copy as needed.

Telemetry: it would be nice to understand the % of users who keep the default (no association), how many pick a specific static schema, and how many switch to server schema. (We don't need to collect any identifying information about which server or anything, just how many switch to that feature.)

Show required inputs, misc other details in the description, and links to more docs (where applicable).

They have already been copied in, we need to run them.

See json-schema-org/json-schema-spec#180 (comment) -- this might match our semantics a little better.

• Hyperlink to template parts elsewhere in the workspace
• Teach the extension about parameters for intellisense
• Help generating a template ("factor out as template"?)

There is a README line that says "Currently this library uses libsecret so you may need to install it before running npm install."

Does this mean any machine that uses code that uses their lib on linux needs this installed? If so, seems problematic.

https://github.com/atom/node-keytar

The bulk of the schema is hand-generated, and we use yaml-schema-service / generate-yaml-from-json to insert tasks into it. Ideally the base schema would be a templatized file independent of the code, and we would use a simple token replacement to insert the task parts.

Macros are string replacements using $( )

Object expressions use the form $[ ]

Right now we activate on *, which is always.

What we want is to activate on language or onCommand:

https://code.visualstudio.com/docs/extensionAPI/activation-events#_activationeventsoncommand

We won't package it with the extension.

Cancel and timeout fields go to job?
Add parallel under strategy

When the language server checks each entry for anyOf and none match, then it chooses an arbitrary branch to use for reporting errors. This can mean that if you mess up one property name, suddenly all your previously-correct properties are reported as not matching.

Using the attached schema, the attached .yml should validate. At the root of the schema, it should match "#/definitions/jobsAtRoot" because of the jobs keyword. It fails to match and VS Code complains that jobs is unexpected.

If I temporarily remove both "#/definitions/jobAtRoot" and "#/definitions/phaseAtRoot", it validates. Also if I remove the resources keyword, it validates.

Ideally we would generate the extension's schema from the server-side objects.

Configuring GitLens was working and now it seems to require configuring in the workspace instead of the extension. We would prefer to configure it in the extension so we don't have to force the user to do it.

We were looking into this because GitLens has over 8.5 million installs so it's likely our users will be using it.

Example:

steps:
- task: NuGetToolInstaller@0

By adding one of the non-required inputs, the error goes away.

There's a preset list of task identifiers. In reality, the task name can be practically anything since tasks can be created and installed by anyone, not just Microsoft.

When you add an env: expression, those variables become available for use in scripts. We need to recognize those and allow them for autocomplete.

Even more interesting: a ##vso command can write a new output variable. That variable is available in downstream steps.

In a bash block, we should switch to syntax highlighting Bash. Similar for the other script languages.