Closed SuperJMN closed 3 years ago
SebastianSchuetze
commented
3 years ago thanks for posting
The cmdlet is not running a pipeline but it is testing the yaml code and returns errors if there are some. It is for checking yaml code without have to commit it.
DarqueWarrior
commented
3 years ago Can we close this? It appears to be working as expected right?
SuperJMN
commented
3 years ago In my opinion, the cmdlet should be a bit more explanatory when it comes to errors.
SebastianSchuetze
commented
3 years ago What would you suggest to be more explanatory?
Better documentation?
The API itself does not return an error. So it seems that for the API it was fine.
For easier check could you paste the yaml code here that you made the call with so we can check the return value and also see if something can be improved?
We need the help of others to improve this as we do this in our spare time. Not a full time job here. ☺️
SebastianSchuetze
commented
3 years ago @SuperJMN I checked your case again. Your POST man test is returning the same response as the cmdlet. The cmdlet help is also helpful in explaining what it does.
If you are looking for starting a pipeline you always have to commit the YAML and then run the pipeline because the agent running the pipeline always has to have the code itself.
But I made a small effort to improve the help a bit and make it clearer.
PS C:\> Get-Help Test-VSTeamYamlPipeline -Detailed
NAME
Test-VSTeamYamlPipeline
SYNOPSIS
Tests the commited YAML pipeline files to check for inconsitencies. Now, you can try out
a YAML pipeline without committing it to a repo or running it. Given an existing
pipeline and an optional new YAML payload, this function will give you back the full
YAML pipeline.
SYNTAX
Test-VSTeamYamlPipeline [[-PipelineId] <Int32>] [-FilePath <String>] -ProjectName
<String> [<CommonParameters>]
DESCRIPTION
Tests the commited YAML pipeline files to check for inconsitencies. Now, you can try out
a YAML pipeline without committing it to a repo or running it. Given an existing
pipeline and an optional new YAML payload, this function will give you back the full
YAML pipeline.
PARAMETERS
-PipelineId <Int32>
Id of the YAML pipeline to be checked
-FilePath <String>
Path to the file that should be checked
-ProjectName <String>
Specifies the team project for which this function operates.
You can tab complete from a list of available projects.
You can use Set-VSTeamDefaultProject to set a default project so you do not have to
pass the ProjectName with each call.
<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug,
ErrorAction, ErrorVariable, WarningAction, WarningVariable,
OutBuffer, PipelineVariable, and OutVariable. For more information, see
about_CommonParameters (https://go.microsoft.com/fwlink/?LinkID=113216).
-------------------------- Example 1 --------------------------
Test-VSTeamYamlPipeline -Project DemoProject -PipelineId 24 -FilePath
'./azure-pipelines.yml'
Name Id url
state
---- -- ---
-----
-1 https://dev.azure.com/devsdb/3428bdd7-9fed-4c30-a6c9-fcb52f084ab9/_apis/pipelines
/24/runs/-1 unknown
This example checks the YAML pipeline with ID 24 and the file './azure-pipelines.yml'
for consistency on Azure DevOps to see if the changes still work.
-------------------------- Example 2 --------------------------
$yamlOverride = [string](Get-Content -raw $FilePath)
Test-VSTeamYamlPipeline -Project DemoProject -PipelineId 24 -YamlOverride $yamlOverride
This example checks the YAML pipeline with ID 24 and the content of a yaml file in the
variable $yamlOverride for consistency on Azure DevOps to see if the changes still work.
-------------------------- Example 3 --------------------------
$yamlOverride = [string](Get-Content -raw $FilePath)
Test-VSTeamYamlPipeline -Project DemoProject -PipelineId 24
This example checks the YAML pipeline with ID 24 for consistency on Azure DevOps to see
if the existing YAML of the pipeline works.
I'm trying to do a test run of my local pipeline.
Using Postman, everything goes fine, as you can see here:
Steps to reproduce
Expected behavior
I would expect a new run for my pipeline
Actual behavior
Environment data
OS
Server