Allow for duplicate tasks in a single stampede list with different config

This story has 2 main implications that will need to be addressed: 1) With 2 tasks with the same task id in the list, how do we differentiate them in the UI of GitHub checks and in the portal? 2) We should be clear on how config is applied, not just across the tasks but in the entire system. Maybe overkill for just this story, but probably worth going ahead and addressing as this involves changes in the same code area.

1) Task ids and titles

First off, when we add a task to the active list, we should go ahead and add in the position index for the task so that we get a unique id, even if there are duplicate task ids. So for example we would get: pr-standards-5 and pr-standards-6 if we had them twice in the list (and assuming there are 5 other tasks in the list starting at 0). We also should clarify our params a bit as this might should go in the external_id field, but that could be named better.
Secondly, for titles we show in the UI we should allow a task to specify an alternate title when placed in the config for a repo. By default the title is pulled from the tasks list that is configured with the server. But a repo should be able to change the title:

  tasks:
    - id: unit-tests-ios
      title: My title for this task

How the tasks will be displayed separately in the UI and internally can be identified as separate as well.

2) Config

The overall goal of the system is to provide the correct hooks for system admins to change/manage the configuration of anything in the system, regardless of what is in each repo's .stampede.yaml. This is related to this issue because in the repo .stampede.yaml we have a general config section, then each task also has a config node.

So to make this work we need a very understandable config model so we know exactly which config parameters are going to be used for a particular task.

The end goal here is to replace the current config object sent when a task is to be executed. This config node needs to contain the final config values that are required to run the task. It should look something like:

"config": {
  "key": "value"
  "keySource": "..."
}

Where each key has a value, but also has a keySource that indicates where the value came from.

Task config starts with what is set in the tasks.yaml file that the server is configured with. This represents the master list of parameters the task is able to use. We will also be adding some documentation fields to that file as well so it can be documented.

Another consideration here is that we allow the repo config to be overridden by setting it in Redis. As far as the config flow goes, the flow is the same, just replace the repoConfig with either the file from the repo, or the override from Redis.

Given all these facts, the flow of config parameters is as follows:

1) Tasks.yaml 2) Server default 3) Repo Config defaults section 4) Repo Config task section 5) Server override

Tasks.yaml

The key is first defined in the tasks.yaml for the task:

- id: task-id
  title: task title
  config:
    - key: configParam1
    - key: configParam2

Server default

Default values are specified in a defaults.yaml file that is loaded by stampede-server.

configParam1: configValue1
configParam2: configValue2

Repo config defaults section

In the .stampede.yaml file for the repo, there is a config section at the top of the file. Example:

config:
  - configParam1: configValue1
  - configParam2: configValue2

Repo config task section

Where each task can specify a value

pullrequests:
  tasks:
    - id: task-id
      config:
        - configParam1: configValue1
        - configParam2: configValue2

Server override

Default values are specified in a overrides.yaml file that is loaded by stampede-server.

configParam1: configValue1
configParam2: configValue2

davidahouse / stampede-server