Remove repos property from config.yml

[samuelbernardolip]

Improve current implementation so criteria properties are in accordance with the concepts being represented:

• projects (software or platforms) -> stages
• build tools -> steps

So the expected result would allow to change from:

sqa_criteria:
  qc_style:
    repos:
      whatever-project-id:
        commands: [ .. ]

into one of the following representations:

• in case there is only one project to be tested

  sqa_criteria:
  qc_style:
  builders:
    - commands: [ ..]
    - tox: [...]
    - maven: [...]

• if there is more than one project to test:

  whatever-project-id:
  sqa_criteria:
  qc_style:
    builders:
      - commands: [ ..]
      - tox: [...]
      - maven: [...]

@orviz my doubt here is about placing project in the level above criteria, or if project must be a property of the criterion... This approach allows for project dependency, for example:

whatever-project-id1:
  sqa_criteria:
    qc_style:
      builders:
        - commands: [ ..]
        - tox: [...]
        - maven: [...]
whatever-project-id2:
  sqa_criteria:
    qc_style:
      builders:
        - commands: [ ..]
        - tox: [...]
        - maven: [...]
whatever-project-id1-again:
  sqa_criteria:
    qc_style:
      builders:
        - commands: [ ..]
        - tox: [...]
        - maven: [...]

The jenkins stage name will be defined by project id followed by criterion name, in this case are "whatever-project-id1 qc_style", "whatever-project-id2 qc_style" and "whatever-project-id1-again qc_style". In each stage can be run the selected criterion from the set defined for each project. This is also important thinking in deploy or docker-registry stages, that can be placed in or outside the project itself.

[orviz]

@orviz my doubt here is about placing project in the level above criteria, or if project must be a property of the criterion... This approach allows for project dependency, for example:

whatever-project-id1:
  sqa_criteria:
    qc_style:
      builders:
        - commands: [ ..]
        - tox: [...]
        - maven: [...]
whatever-project-id2:
  sqa_criteria:
    qc_style:
      builders:
        - commands: [ ..]
        - tox: [...]
        - maven: [...]
whatever-project-id1-again:
  sqa_criteria:
    qc_style:
      builders:
        - commands: [ ..]
        - tox: [...]
        - maven: [...]

I see an inconvenience in using the project as a level above the criteria. In your example, I understand that whatever-project-id1-again has to be a duplicate of whatever-project-id1, which makes the pipeline definition more bulky. This duplication is avoided when using the project inside the criterion.

On the other hand, is there any reason to add builders key?

[samuelbernardolip]

I see an inconvenience in using the project as a level above the criteria. In your example, I understand that whatever-project-id1-again has to be a duplicate of whatever-project-id1, which makes the pipeline definition more bulky. This duplication is avoided when using the project inside the criterion.

Yes that is always an issue, even if we place criteria or project outside. The use case was to show a dependency between projects. So suppose that project-id2 depends on the check success of project_id1 for criteria xpto1, and then later project-id1 criteria xpto2 depends on project-id2 to pass all defined checks. The point is that I find the dependency concept associated with the project and not the criterion itself, that's why I placed project above criteria.

On the other hand, is there any reason to add builders key?

To get builders label as a generic definition, so I can collect the steps to apply into the stage and using an array also allows to repeat the commands or build tools as a step if required.