c7904bc0b5
Store each independent project stanza as its own config object, instead of collecting them all together and synthesizing a single object from all of them. This will later allow us to re-use unchanged project stanzas across dynamic configuration changes. This requires changes to the way project-pipelines are created. Rather than creating them during configuration loading, they are now created from the project and project-template config objects when the job graph is frozen. We used to create a fixed job list for every project-pipeline, and in that job list, we would add implied branch matchers to the project-pipeline job variants based on where the project stanza was located. This means that if a 'project:' stanza within a 'stable' branch listed a certain job, that project-pipeline job variant would match the 'stable' branch because of the implied branch matcher added to the project-pipeline job variant. The same applies to template *invocations* -- that is, where a project stanza has a 'templates:' attribute. The templates themselves didn't have implied branch matchers. All of that together means that now that we are keeping all of the individual project stanzas around (instead of combining them at configuration time) we can move the implied branch matchers from the project-pipeline job variants to the project stanzas themselves. Then, when we later dynamically construct the project config based on the enqueued item, we can just use or ignore entire project stanzas based on their implied branch matchers. We no longer need to modify the project-pipeline job variants. Change-Id: Ia984ae5c1a4825528a9fa3ea6eb254b75af9b4dd
10 lines
312 B
YAML
10 lines
312 B
YAML
---
|
|
features:
|
|
- |
|
|
The :attr:`project.default-branch` option is now documented. It has been
|
|
supported since version 3.0.0, but was omitted from the documentation.
|
|
deprecations:
|
|
- |
|
|
The ``merge-mode`` and ``default-branch`` attributes may no longer appear
|
|
in a :ref:`project-template` stanza.
|