You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The YAML parsing reports errors when trying to queue a YAML build but often the actual error is well beyond the truncated error message that is shown. It would be nice if the YAML parser would provide a more focused error message around the actual code (ideally with lines if applicable) that is causing the error instead of just showing the first part of the script.
Example 1 - Script is longer than 2000 characters. The only way to figure out how much you have to truncate is to load the script into an editor that counts characters. What makes this difficult at best is the fact that it is unclear what counts to the parser. I noticed that template expressions cause the entire block to be put inside a format message where the expressions are replaced with ordinal positions. So is this part of the char limit or the original template expression? What about the spaces before the start of the line when doing something like a multiline PowerShell script where you have to put spaces to get the indentation proper? Rather than memorizing, playing around with the rules it would be nice if it would just show the line and an indicator where it ran out of room.
Example 2 - Body has ${ elements such that parser says a $ is invalid. This is a complex PowerShell script mixing template expressions, PowerShell variables, a hashtable, regular expression string with nested quotes and $. The only message I get is that the $ is invalid but there is no easy way to figure out where this is actually occurring. Note that line/column information probably isn't sufficient here since the code is converted to a format call. It would be unclear whether this is the original code or the modified code.
The text was updated successfully, but these errors were encountered:
I should point out that the error message does contain line, column information but it doesn't map to what I see in the script. In my case the line # points to something that does have $ in it but the column is whitespace. Copying that entire line to earlier in the script doesn't change the error in any way so if the line itself was problematic I would have expected moving the line to trigger an error earlier in the parsing.
In order to consolidate to fewer feedback channels, we've moved suggestions and issue reporting to Developer Community. Sorry for any confusion resulting from this move.
The YAML parsing reports errors when trying to queue a YAML build but often the actual error is well beyond the truncated error message that is shown. It would be nice if the YAML parser would provide a more focused error message around the actual code (ideally with lines if applicable) that is causing the error instead of just showing the first part of the script.
Example 1 - Script is longer than 2000 characters. The only way to figure out how much you have to truncate is to load the script into an editor that counts characters. What makes this difficult at best is the fact that it is unclear what counts to the parser. I noticed that template expressions cause the entire block to be put inside a format message where the expressions are replaced with ordinal positions. So is this part of the char limit or the original template expression? What about the spaces before the start of the line when doing something like a multiline PowerShell script where you have to put spaces to get the indentation proper? Rather than memorizing, playing around with the rules it would be nice if it would just show the line and an indicator where it ran out of room.
Example 2 - Body has ${ elements such that parser says a $ is invalid. This is a complex PowerShell script mixing template expressions, PowerShell variables, a hashtable, regular expression string with nested quotes and $. The only message I get is that the $ is invalid but there is no easy way to figure out where this is actually occurring. Note that line/column information probably isn't sufficient here since the code is converted to a format call. It would be unclear whether this is the original code or the modified code.
The text was updated successfully, but these errors were encountered: