1. Atlassian Labs Avatar Atlassian Labs
  2. Partner Integrations
  3. atlascode
  4. Issues

YAML validator inconsistent with online tool and Pipelines runtime

Issue #66 open
Gary Breavington created an issue

I have a pipelines yml file, and the validator in the plugin doesn’t agree with what’s valid YAML with both the online validation tool Atlassian provide, as well as the Pipelines runtime (i.e. whatever engine parses the yml file when a Pipeline runs).

There are a couple of issues I think I see. One set of problems is down to the use of YAML anchors in my yml file. Using a modified version of the example from this page:

definitions: 
  steps:
    - step: &build-test
        name: Build and test
        script:
          - mvn package
        artifacts:
          - target/**

pipelines:
  branches:
    develop:
      - step: *build-test
        name: build-test-1
    master:
      - step: *build-test
        name: build-test-2

The online validator thinks this is valid, and this would work when run as a pipeline job.

Issue 1 is that the plugin’s yml validator thinks “steps” should not be present on line 2, though according to the YAML Anchors documentation, that is actually how you define an anchor.

Issue 2 is that the validator says that the “name” entries on lines 14 and 17 should not be present. Whilst raising this case, I noticed that the following change means this error will go away, however the validator in the plugin disagrees with the online tool and the actual runtime!

    master: # was line 15 above
      - step: 
          <<: *build-test
          name: build-test-2

It’s nice to have yml syntax validation whilst having the file, though I’m not sure why the file needs to be considered valid locally to be able to run the job on the server. I guess that’s how the plugin works out what there is available to run.

Comments (44)

  2. Jonathan Doklovic Account Deactivated

    Thanks for pointing out these issues. This is definitely a new and somewhat experimental feature so getting bug reports will help us clean some of this up.

    We should be able to correct both of these issues soon.

    It should be noted that the local validation in the extension doesn't actually stop you from commiting the change if it's invalid and the server side should still build it fine. I realize this isn't great right now, but if you know the file is indeed valid, you should be able to commit it and build just fine.

  5. Samuele Reghenzi

    I have an issue similar to this:

    services: - postgres

    This directive ( that is totally fine and works on the pipelines ci) is marked as error in the vscode view : Incorrect type. Expected "object".

  17. Roland van Laar

    Yeah, can this be fixed sooner? When pipelines can’t build due to an error it suggest the validator which says it’s valid. That’s really not fun at all.

  18. Mat Gilbert

    This is still an issue 562 days later. The validator still doesn’t catch things that Bitbucket pipelines fail builds for. It appears to be an indenting issue. Using VSCode.

  19. Amit Edelshtein

    I also noticed 2 issues with the schema:

    1. The condition section is not documented
    2. Arrays passed to pipe arguments as documented here generate a validation error

    ‌

  23. Inger Klekacz

    This issue is now over 2 years old. 6 other issues have been opened as duplicates of this, so the impact of this bug is greater than the vote count on this would have you believe. Pipelines has come a long way, but please please fix this bug.

  25. Alex Ho

    Are there any updates?

    @Pablo Tejada, thanks for suggestion, however, it did not resolve the pipeline warnings

  27. Sebastian Fredriksson Bernholtz

    @{557057:3695b794-cde3-43a2-99aa-c0fc6151b754} Is this being worked on? To fix many of the reported issues it should just require updating the json schema being used by extensions.

  29. Nick Rundquist

    Hello all,

    Obviously our schema for bitbucket-pipelines.yml has diverged from the one actually used by Bitbucket Pipelines. i’m curious to know if you are using the schema to edit the YAML file in VS Code or if you’re creating the file elsewhere and there are non-existent errors being flagged one it’s opened in VS Code.

  30. Amit Edelshtein

    For me it’s mostly getting errors while editing in VS Code or any other editor that automatically fetches the schema for tooltips and validation. It’s really annoying to get errors without being able to identify if it’s an actual problem or a schema problem. In some ways it’s better to not have a schema at all than being constantly distracted by red squigglies.

  31. Inger Klekacz

    The age of this ticket (and the other ones just like it) and Atlassian’s prolonged refusal to fix the issue when it’s literally a schema change is the best argument I’ve ever seen for open source software.

  32. Roland van Laar

    @Nick Rundquist In a way thanks for asking.

    The bare minimum would be to fix the online validation tool. It doesn’t help that a broken run suggest using the validator which says it’s valid.
    Next best, update your definition of done for pipelines changes so that it includes schema fixes.

  33. Sebastian Fredriksson Bernholtz

    @Nick Rundquist Thanks for looking at this!

    I’m using the schema to validate the YAML file while editing it in VSCode.

    I use it because it lets me know immediately if there are any issues, instead of waiting for it to be committed, pushed and fail in the pipeline - alternatively adding a manual process of validating the yaml in the online validation tool 🤮 after every edit.

    The validation and code completion also means that I don’t have to search for and refer to the documentation as often. It allows me to stay in VSCode through the entire process. While this is not something that takes heaps of time, the proportional reduction huge. Having to search for errors that aren’t actually errors add some of that time back.

  34. Matt Miller

    A temporary fix in vscode for this is to update "additionalProperties": true in the pipelines-schema.json. By default this is false, change it to true to allow properties that are not in the schema, otherwise you will need to manually add them.

    ‌

  36. Cord Slatton

    the condition property is still unsupported! This has been a really long time. Please add this to the schema.

  37. Cord Slatton

    @Matt Miller - how can I set the "additionalProperties": true for the pipelines-schema.json file? It is coming from Atlassian via their extension for VSCode…

  39. Tim Cambrant

    @{557057:3695b794-cde3-43a2-99aa-c0fc6151b754} Could we please get some sort of status update on this?

  43. Cord Slatton

    It would also be really great to see this expanded to have excludePaths as well as the existing includePaths.

  44. Tom Chan

    any update on this…it is not rocket science but it took year for update

    also agree that excludePaths is good for real world usage

  45. Log in to comment
Assignee
Type
bug
Priority
major
Status
open
Component
Bitbucket
Votes
70
Watchers
71