Skip to content
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

Added execution engine configs #134

Merged
merged 12 commits into from
Feb 7, 2022
Merged

Added execution engine configs #134

merged 12 commits into from
Feb 7, 2022

Conversation

applejag
Copy link
Contributor

@applejag applejag commented Jan 28, 2022

Summary

  • Added config:

    ci:
      # old way:
      triggerUrl: http://jenkins.local/trigger
      triggerToken: changeit
    
      # new way:
      engine:
        id: jenkins # defaults to "primary"
        name: Jenkins # defaults to "Primary"
        url: http://jenkins.local/trigger # defaults to ci.triggerUrl
        token: changeit # defaults to ci.triggerToken
    
      engine2:
        id: wharf-cmd # defaults to "secondary"
        name: wharf-cmd # defaults to "Secondary"
        url: http://wharf-cmd-provisioner/api/trigger
        token: changeit
  • Added response models for engines

  • Added endpoint GET /api/engine

  • Added query parameter ?engine= to "start build" endpoint

  • Added engine ID to build table

  • Added engine to build responses via engineLookup

  • Added a new problem type: /prob/api/engine/no-default

Motivation

Allows for a more natural transition over to wharf-cmd instead of Jenkins, as the user can specify what execution engine they want to use on a per-build basis.

With such, we can have Jenkins as the primary and default engine until wharf-cmd is feature-complete with our Jenkins implementation. Then we could switch so wharf-cmd is the primary engine and keep Jenkins as a secondary to allow using that one if the wharf-cmd implementation fails.

The config design is a bit weird. The reason is that Viper, the config library we're using via wharf-core, doesn't support arbirary names or indices for environment variables. It can only perform lookups on fields it already recognizes. See #132 for the initial YAML config design using a map[string]Engine. This config design limits us for now to only having a primary and a secondary engine, but can be expanded further by adding ci.engine3, ci.engine4, etc. From the REST API perspective, it's just a list of engine definitions.

After merge

  • Create PR to iver-wharf.github.io for docs on new problem type: /prob/api/engine/no-default

Closes #132

@applejag applejag added the enhancement New feature or request label Jan 28, 2022
@applejag applejag self-assigned this Jan 28, 2022
@applejag
Copy link
Contributor Author

applejag commented Feb 7, 2022

I pushed two minor bug fixes. Hope you're OK with me merging without you review again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add option for selecting execution engine
3 participants