8000 Introduce v1 syntax · Issue #126 · mumoshu/variant · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Introduce v1 syntax #126

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mumoshu opened this issue Dec 17, 2019 · 1 comment
Closed

Introduce v1 syntax #126

mumoshu opened this issue Dec 17, 2019 · 1 comment

Comments

@mumoshu
Copy link
Owner
mumoshu commented Dec 17, 2019

I'd like to introduce the next generation of Variant's configuration syntax with a few additional features, which is basically an extension over #125.

apiVersion: v1

# See https://github.com/mumoshu/variant/issues/113
config:
  # Load `{{.Config.Values}}` from foo.yaml and bar.yaml.
  # Use contexts and directories instead for layering
  files:
  - foo.yaml
  - bar.yaml
  contexts:
  - cluster1,dev
  directories:
  - test
  - config/environments
  # This allows you to define default values
  values:
  - foo: bar
  # Supports https://github.com/variantdev/vals refs
  - ref+vault://mykv/mydoc#/myfield

# variantdev/mod dependencies.
# Dependencies are automatically loaded from `variant.lock`.
# If variant.lock is missing, it will automatically retrieve the latest version numbers and creates `variant.lock` from it.
# When variant.lock exists, you can manually run /variant mod build [--pull-request] to (re)generate and optionally submit a pr
dependencies:
  helmfile:
    releasesFrom:
      dockerImageTags:
        source: quay.io/roboll/helmfile
    version: "> 0.94.0"

# vavriantdev/mod provisioners.
provisioners:
  # If the target file is missing, variant will automatically create the file
  # You can manually run /variant mod build --pull-request to (re)generate and optionally submit a pr
  regexpReplace:
    Dockerfile:
      from: "(FROM helmfile:)(\\S+)(\\s+)"
      to: "${1}{{.Dependencies.helmfile.version}}${3}"
  executables:
    # Adds alias dockergo='docker run golang:{{.version}}' to $PATH
    dockergo:
      platforms:
        # Adds $VARIANT_MOD_PATH/mod/cache/CACHE_KEY/dockergo to $PATH
        # Or its shim at $VARIANT_MOD_PATH/MODULE_NAME/shims
      - docker:
          command: go
          image: golang
          tag: '{{.version}}'
          volume:
          - $PWD:/work
          workdir: /work

commands:
  hello:
    script: |
      echo hello
  app deploy:
    workflow:
      app1-enabled:
        type: bool
      app1-dir:
        type: string
        from:
        - env
        - config
        - script: somescript
          runner:
             image: foobar:tag
             command: somecmd
             args: [arg1]
      app1:
        command: {kubectl-apply: {file: "{{ .app1Dir }}"}}
        condition: .app1Enabled
        needs: [app1-enabled, app1-dir]
        #after: [parma1] if you don't refer to `.Deps.param1` from the template and only want to control execution order, not the existence of param1
      app2:
        task: {helm-upgrade: {chart: charts/mychart}}

TODOs:

  • Implement Variant GitHub Action
  • In addition to triggering commands via slash commands on github issues/ps, add support for triggering via issue creation(any /slashcmd contained in the issue body are triggered)
@mumoshu
Copy link
Owner Author
mumoshu commented Feb 11, 2020

Closing this as covered by Variant 2. More precisely, Variant 2 gives bascially this(workflows, concurrency, DAGs) in either JSON or HCL-based configuration syntax. See #129 fore more information.

@mumoshu mumoshu closed this as completed Feb 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant
0