Steps

---
# This document is displaying all the required tags
# to run a postgre database for the duration of a pipeline.
steps: 
  - name: Hello World
    image: alpine:latest
    commands:
      - echo "Hello, Vela User"

---
steps:
    # Unique identifier for the container in the pipeline.
  - name: Hello World

---
steps:
    # Docker image used to create ephemeral container. 
  - image: alpine:latest

---
steps:
    # Declaration to configure if and when the Docker image is pulled.
    # By default, the compiler will inject pull with value not_present but
    # accepts the following values: always, never, not_present, on_start
  - pull: always

---
steps:
    # Sensitive variables to injected into the container
    # environment as upper case env. i.e. GIT_USERNAME=vela
  - secrets: [ git_username ]

---
steps:
    # Sensitive variables to injected into the container
    # environment as upper case env. i.e. GIT_USERNAME=<secret_value> 
  - secrets: 
      # The source is the "name:" of a secret within the
      # parent "secrets:" yaml tag
      - source: username
      # The target is the desired environment key accessible during
      # the container runtime.
        target: git_username

---
steps:
    # Variables to injected into the container environment
    # using a map style syntax.
  - environment:
      DB_NAME: vela

---
steps:
    # Variables to injected into the container environment
    # using an array style syntax.
  - environment:
      - DB_NAME=vela

---
steps:
  - ruleset:
      # As shown below this step will execute if the build
      # branch is stage or main.
      branch: [ stage, main ]

---
steps:
  - ruleset:
      # This extends the ability to start new builds through interactions
      # within a pull request. As shown below this will run a step if a “run build”
      # comment is added to the bottom of a pull request.
      comment: [ "run build" ]

---
steps:
  - name: Event Ruleset
    ruleset:
      # As shown below this step will execute if the build
      # event is push or pull_request. The available events are:
      # comment, push, pull_request, tag, and deployment.
      event: [ push, pull_request ]
  - name: Scope Events
    ruleset:
      # For pull_request and comment events, specifying an action will
      # further scope when the step is executed. These actions include
      # opened, synchronized, and edited for pull_request; created and 
      # edited for comment. To specify an action, use a ":" as shown below.
      event: [pull_request:opened, comment:created]

      # Note: specifying pull_request is the same as [pull_request:opened, pull_request:synchronized]. 
      # Specifying comment is the same as [comment:created, comment:edited]. 

---
steps:
  - ruleset:
      # As shown below this step will execute if file README.md, any file of type *.md
      # in the root directory or any file in the test/* directory has changed.
      path: [ README.md, "*.md", "test/*" ]

---
steps:
  - ruleset:
      # As shown below this step will execute if repo exists within the target GitHub
      # organization or the repo is the go-vela/docs repository.
      repo: [ "target/*", "go-vela/docs" ]

---
steps:
  - ruleset:
      # As shown below this step will execute if the build status is failure or success.
      status: [ failure, success ]

---
steps:
  - ruleset:
      # As shown below this step will execute if the build ref is dev/* or test/*.
      tag: [ dev/*, test/* ]

---
steps:
  - ruleset:
      # As shown below this step will execute if the build target is stage or production.
      # This tag is only compatible with deployment and schedule events.
      target: [ dev/*, test/* ]

---
steps:
  - ruleset:
      # As shown below this will overwrite Vela's default behavior to
      # allow the build to continue the sequential step pipeline when this step fails.
      continue: true

---
steps:
  - ruleset:
      # As shown below this will overwrite Vela's default behavior to use a 
      # filepath matcher and instead evaluate all rules with regex. The available
      # matchers are: filepath, and regexp.
      # Note: The regexp matcher uses Go's regexp package. You can find documentation
      # at https://golang.org/pkg/regexp/syntax/
      matcher: regexp
      branch: foo-\\d

---
steps:
  - ruleset:
      # As shown below this will overwrite Vela's default behavior to use an 
      # "or" behavior when comparing all ruleset rules.
      # The available operators are: and, and or.
      operator: or

---
steps:
  - ruleset:
      # As shown below this will tell the ruleset to only execute
      # this step when the branch is main and event is push.
      if:
        branch: main
        event: push

---
steps:
  - ruleset:
      # As shown below this will overwrite Vela's default behavior to tell the ruleset
      # to only execute this step when the branch is not main and event is not push.
      unless:
        branch: main
        event: push

---
steps:
    # Extra configuration variables specific to a plugin. All tags within the 
    # parameters tag are injected environment variables into the
    # container as PARAMETER_<TAG_NAME>.
    # As shown below this step will execute a plugin that needs two fields:
    # PARAMETER_REGISTRY=index.docker.io
    # PARAMETER_REPO=octocat/hello-world,go-vela/docs
  - parameters:
      registry: index.docker.io
      repo: [ go-vela/hello-world,  go-vela/docs ]

---
steps:
    # Execution instructions to run inside the container. 
  - entrypoint:
      - echo "Hello, World"

---
steps:
  - template:
      # Name of template to inject in the step. The name must map
      # to an existing template in the parent "template" tag.
      name: example

---
steps:
  - template:
      # Variables injected into the template. Variables can be any
      # primitive or complex YAML types but the corresponding template
      # needs to understand how those templates are to be used.
      vars:
        tags: [ latest, "1.14", "1.15" ]
        pull_policy: always
        commands:
          test: "go test ./..."
          build: "go build ./..."  

---
steps:
    # Commands to execute inside the container.
  - entrypoint:
      - /bin/pwd
      - /bin/ls

---
steps:
    # Run the container in a detached (headless) state. Similar to the 
    # "services:" tag this will create a container that can be used throughout
    # the duration of the pipeline.
  - detach: true

---
steps:
    # Set the user limits for the container.  
  - ulimits:
      - name: foo
        soft: 1024
      - name: bar
        soft: 1024
        hard: 2048

---
steps:
    # Run the container with the foo user.
  - user: foo