Support #266

Semantics of the "slaves" feature

Added by Florian Lier over 10 years ago. Updated almost 10 years ago.

Status:ResolvedStart date:2014-06-07
Priority:HighDue date:
Assignee:-% Done:

100%

Category:build-generatorSpent time:-
Target version:-

Description

It is not completely clear to me how the "slaves" feature works.

"slaves":         [ "master" ],
"slaves.ubuntu":  [ "@{slaves}" ],
"slaves.linux":   [ "@{slaves.ubuntu}" ],

This means, that the used distribution is build on "master" and also (?) on slaves labelled with ubuntu, or linux?

The problem is that master is fine for local building (aka mobile Jenkins) however, if we create jobs on ci.toolkit
we don't want the distro to be built on the master. Do one need to change this on the fly before actually adding jobs
to ci.toolkit?

Associated revisions

Revision 012181a8
Added by Johannes Wienke almost 10 years ago

Adapt distributions according to new requirements

  • Add patterns for orchestration job names, fixes #324
  • remove slaves from distributions since they have reasonable defaults
    in the templates now, fixes #266
  • remove bla-name variable, refs #241
  • Clean up name and folder variables as much as possible, refs #228

Probably fixes #290

History

#1 Updated by Jan Moringen over 10 years ago

  • Status changed from New to Feedback

Explanation of Concrete Example and Current State

The snippet

"slaves":         [ "master" ],
"slaves.ubuntu":  [ "@{slaves}" ],
"slaves.linux":   [ "@{slaves.ubuntu}" ],

should be a "user-level" (i.e. no special semantic in the generator) cascade of variables, slaves being the most generic variable, slaves.ubuntu being the most specific one. The cascade is achieved using the variable substitution mechanism of the generator (See section in source:README#L49 for some notes regarding the substitution syntax).

The idea is that the value can be overwritten at each level of specificity, for example "for all Linux build jobs" or "for all Ubuntu build jobs".

Future Work

The whole cascade and its use by templates is a "only" a matter convention. However, we should probably still improve and document this convention.

In my opinion, the goal would be having specific variables for each kind of deployment and a cascade of default values for convenience.
  • For example, a kind of deployment could be "local Jenkins, distribution installation mode, Ubuntu Linux platform". This deployment could use a variable like slaves.local.distribution.ubuntu which may default to the value of slaves.local.distribution.linux and so on.
  • The toolkit case could use something like slaves.toolkit.distribution.ubuntu.

Next Steps?

To stress the point again: this a matter of organization, planning and convention, not a current or future feature of the generator. As a result, we could start by collecting use-cases like the above example and start to flesh out the requirements and details of those. I would be happy to adapt the generator where necessary if we had this kind of use-case analysis.

#2 Updated by Johannes Wienke over 10 years ago

  • Assignee deleted (Johannes Wienke)

#3 Updated by Johannes Wienke almost 10 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

Applied in changeset projects|commit:012181a87a29a02758751d9c8d4595357a165be5.

Also available in: Atom PDF