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 oslo CLI as validation is a great first step to automate everything. We can build a container image, and it gets used in CI/CD workflows and deployments.
Thinking of schema validation in (cloud) IDEs, such schema spec should be available online. Hosting the YML or JSON representation somewhere as single source of truth is easy. Building a plugin which locally validates the spec with live linting is a little harder.
The hardest part is to lint and validate, and build a request-response model which can be automated. The idea is to provide a REST API endpoint for OpenSLO where you'll POST the OpenSLO config file against, and get feedback from the parser/linter.
Future iterations of the spec may allow things like include or more DSL related stuff. Building a unique interface (CLI and API )
Proposal
Extend oslo to run a webserver which accepts a POST request to /v1/spec/lint
Build a public server which responds to requests (may need fleet scaling behind a fleet to ensure availability)
Document how to build your own API host / proxy e.g. in a Kubernetes cluster
The text was updated successfully, but these errors were encountered:
dnsmichi
changed the title
REST API endpoint /v1/spec/lint to extend automation remote environments (oslo CLI extension)
REST API endpoint /v1/spec/lint to extend automation in remote environments (oslo CLI extension)
Jun 11, 2021
Problem to solve
The oslo CLI as validation is a great first step to automate everything. We can build a container image, and it gets used in CI/CD workflows and deployments.
Thinking of schema validation in (cloud) IDEs, such schema spec should be available online. Hosting the YML or JSON representation somewhere as single source of truth is easy. Building a plugin which locally validates the spec with live linting is a little harder.
The hardest part is to lint and validate, and build a request-response model which can be automated. The idea is to provide a REST API endpoint for OpenSLO where you'll POST the OpenSLO config file against, and get feedback from the parser/linter.
Future iterations of the spec may allow things like
include
or more DSL related stuff. Building a unique interface (CLI and API )Proposal
/v1/spec/lint
Inspiration
/ci/lint
, discussed in this blog post: https://about.gitlab.com/blog/2021/04/21/devops-workflows-json-format-jq-ci-cd-lint/ and documented at https://docs.gitlab.com/ee/api/lint.html#validate-the-ci-yaml-configurationThe text was updated successfully, but these errors were encountered: