oneci's Introduction

⚠️ This repository is no longer maintained 😢

If you're interested in this project, send me a message! ✉️

oneci

OneCI specification & tools (in development)

help wanted

goal

The goal of this project is to create a vendor agnostic configuration format for CI/CD runners to make it easier for projects to switch platforms, and tooling around it.

spec

The to be developed OneCI specification would incorporate common features from various CI vendors, like steps, conditions, environments, matrix expansion, deployment, etc.

adapters

Various adapters could be developed for conversion to/from the OneCI spec to platform specific formats to make migrations easy.

packages

In order to help adopt the specs, various tools could be created alongside the spec in a monorepo containing these packages:

spec: the spec itself as markdown doc and json-schema (or typescript or some other convenient interface)
adapter-*: adapters for various ci platforms
core: functions to validate and convert a configuration object into other formats
cli: wrapper around the core for command line usage
web: wrapper around the core for web usage

list of ci platforms

There are many, but let's start with:

Travis
AppVeyor
GitLab runner
Bitbucket Pipelines
CircleCI
Drone

oneci's People

Contributors

Stargazers

Watchers

oneci's Issues

Publish flow

Implement & test auto-publishing with semantic-release. Not sure how this integrates with lerna though.

https://github.com/atlassian/lerna-semantic-release might help, but needs https://github.com/atlassian/cz-lerna-changelog which is not actively maintained:

Please note that this repository is not actively maintained as it's not actively used here. We are more than happy to accept PRs however. 😀

https://github.com/Updater/semantic-release-monorepo might be another option, but is not actively maintained (as explained by semantic-release/semantic-release#193 (comment))

There's chatter in the thread mentioned above, so it might also be solved from within the semantic-release package itself in the future, who knows.

Research common platform configuration formats

What use cases do various platforms support? Can we extract some commonalities from their various proprietary configuration schemas? What are the most important features we should absolutely include in an initial release. Could we add non-controversial features first, and discuss controversial features or implementations later before adding it to the spec?

Who can we involve as part of this process? Any stakeholders from the vendors who are willing to keep an eye on the activities here?

hongaar / oneci Goto Github PK