manheim / eds Goto Github PK

"tags" plugins will hold tag metadata to apply to config and pipeline objects.

• provide initial draft of eds.interfaces.tags module
• document module/class/methods using docstrings
• document the plugin properties via the eds.interfaces.tags.Tag.schema attribute

• provide initial draft of eds.interfaces.worker module
• document module/class/methods using docstrings
• document the plugin properties via the eds.interfaces.worker.Worker.schema attribute

add tests for:

• eds.main
• eds.project
• eds.plugin
• eds.event

• provide initial draft of eds.interfaces.pipeline module
• document module/class/methods using docstrings
• document the plugin properties via the eds.interfaces.pipeline.Pipeline.schema attribute

• "eds.yml" files will be validated using a json schema stored at eds.project.Project.schema and implemented in eds.project.Project._validate_schema. The schema will confirm to the format described in the README.
• plugin properties will also be validated using a more specific schema stored in eds.plugin.Plugin.schema (for their respective plugin class) and implemented in eds.plugin.Plugin._validate_schema

implement the "eds.pipeline_provider" interface using Jenkins.

move CI to github actions

when "eds.yml" files include other "eds.yml", they must specify a consistent version of EDS.

• provide initial draft of eds.interfaces.pipeline_provider module
• document module/class/methods using docstrings
• document the plugin properties via the eds.interfaces.pipeline_provider.PipelineProvider.schema attribute

• implement a logging framework, possibly loguru
• support for configurable log levels.
• log level would be parameter to main.main
• log levels can be passed via cli parameter, which would be passed through to main.main
• implement exception logging in except block of main.main

convert the informal interfaces in eds.interfaces to use the formal abc technique, which means requiring plugin implementations to register their classes.

• add an "eds" cli using click in eds.cli
• add the console script entrypoint in setup.py
• cli should create an event using eds.event.Event.init_from_local
• cli should pass event to eds.main.main

In order to discover plugins that need to be installed, we need to support a process where plugin configurations are discovered (which includes their pip install requirements), without the plugins being instantiated, which assumes installation.

create a folder structure like so in EDS src tree

/demo
    /mock_plugins
    /projects
       /grandparent_project
          eds.yml    
       /parent_project
          eds.yml
      /child_project
          eds.yml
    demo.sh
    README.md  

where:

• "mock_plugins" is a python project containing mock plugins for:
  • eds.vcs_provider
  • eds.pipeline_provider
  • eds.worker
  • eds.pipeline
• the project subfolders are setup to exhibit inheritance
• "demo.sh" installs eds, the mock_plugins, and then runs the "eds" cli from the child_project, which runs the plugins.

• implement the eds.vcs_provider interface using github
• the implementation should not assume a local disk for cloning repositories, but rather work with in memory data only.

• provide initial draft of eds.interfaces.vcs_provider module
• document module/class/methods using docstrings
• document the plugin properties via the eds.interfaces.vcs_provider.VcsProvider.schema attribute

fill in missing docstrings across project and then add docstrings compliance test

• provide initial draft of eds.interfaces.task module
• document module/class/methods using docstrings
• document the plugin properties via the eds.interfaces.task.Task.schema attribute

implement the "eds.pipeline" interface using Jenkinsfile

document a hypothetical example of what a real world "eds.yml" might look like.

in 2 forms:

• single file example
• an inheritance example (same as single file, but with layers of inheritance)