Missing property "commands" in .drone.yml file

Drone Support
1

When editing a .drone.yml file using vscode and yaml language support extension, this error comes up: missing property "commands".

The error is thrown inside a docker publishing step, similar to

- name: publish-prod   <-- missing property "commands".
    image: plugins/docker
    settings:
      username:
        from_secret: docker_username
      password:
        from_secret: docker_password
      repo: [...]
      registry: [...]
      dockerfile: ./Dockerfile
      tag:
        - ${DRONE_COMMIT_SHA:0:8}
        - [...]
    when:
      branch:
        - master
      event:
        - push

As you see, steps using the docker plugin don’t require commands to be specified, so I guess it’s an error with the schema definitions.

As a side note, in my drone config file I also have steps with commands in them, and no errors are shown there

2

When editing a .drone.yml file using vscode and yaml language support extension

I am not familiar with any vscode extensions for Drone, but if one does exist, it is not created or maintained by the Drone team. If you are using a third party extension and it is not working as expected you should notify the extension author.

3

The issue is related to the drone schema used to validate the pipeline yaml file. That was info that can help reproducing the bug.

The issue is located in the json stored in https://github.com/SchemaStore/schemastore. Given that is used to validate this project I wrote the bug report here

4

We are not involved in the schema store project and therefore would not be able to help with any schema store bug reports. Perhaps an issue should be raised in the schama store issue tracker instead?

5

Ok didn’t know that. I’ll discuss this issue there then, thank you.
Just to be sure, at the end is not having commands on a pipeline step is to be considered a valid structure?

For reference, this issue is discussed here now

6

most pipeline steps should have a settings or commands (but not both), but there are still valid use cases where neither are provided, such as a plugin that does not require any settings and will therefore have neither, or a container with a custom entrypoint that will have neither.

good:

- name: foo
  image: foo

good:

- name: foo
  image: foo
  commands:
  - echo foo

good:

- name: foo
  image: foo
  settings:
    foo: bar

good:

- name: foo
  image: foo
  entrypoint:
  - /bin/foo

bad:

- name: foo
  image: foo
  settings:
    foo: bar
  commands:
  - echo foo

bad:

- name: foo
  image: foo
  entrypoint:
    foo: bar
  commands:
  - echo foo

bad:

- name: foo
  image: foo
  entrypoint:
    foo: bar
  settings:
    foo: bar