Auxiliary templates are second-class citizens that are used to create inner structures in other models. As such, they do not get transformed to any Jenkins concepts by themselves.

It is easier to understand an auxiliary template if you think about how you’d model a music CD. A “music CD” model might have properties like title and the year of publication, but it also has a list of tracks, where a track by itself is a model that has several attributes, such as the title, the duration, and the composer. In this example, a track is an auxiliary model.

Auxiliary model is also useful for a set of information appear repeatedly across different models. For example, your software development might involve accessing database, which requires several attributes to model (say host, schema, user name, and password.) So as you define various templates that use database, it is convenient to define the database access as an auxiliary model and refer to it from other templates. (The other way to do this of course is via inheritance, where you define this set of attributes in the base template and derive from it elsewhere. See the extensive discussion between inheritance vs composition in object oriented programming languages for more analogy and trade-offs.)