**Note**: The Component versioning where major versions are automatically resolved ONLY works if your components are in a project explicitly set as a CI/CD Catalog, AND only after a release has been created since enabling this setting.
# Aggregate Components
One interesting case to consider is a re-usable CI/CD Component that is simply an aggregator of other CI/CD components. This gets tricky with embedded component versioning. One solution is to make embedded component version a component input variable. This is problematic in the case when the default needs to change. Ideally the new default is in lock-step with a new major version release. This won't work if you're using the release workflow to release a new version of the release workflow, since it will notice that the new default doesn't exist yet (because you're attempting to create it), and the pipeline will fail. A chicken n' egg scenario. In practice, we create new major version, then quickly follow up with a new version that bumps the default embedded component default version. There is a small window when bumping to a major version and the default embedded component versions are out-of-sync. A better approach may be to add a new separate aggregate component per major release. Examples:
I thought this simply provided a group default `.gitlab-ci.yml` if none is provided in a project, but upon closer inspection that isn't what this does (I think). Auto DevOps appears to apply GitLab generic workflows based on detected content in your repo. Doesn't appear to be working, at least not well. Could investigate later.
...
...
@@ -46,3 +53,5 @@ This doesn't work because it's too aggressive. This change rule looks for any f
*Note*: pushing just a tag is a similar scenario, and it is similarly difficult to avoid CI as it's not easy to indicate skip only if the push contains just a tag and nothing else. This assumes user is using `push --follow-tags` or `push --atomic`.
There are [complicated work-arounds](https://stackoverflow.com/questions/73298609/suppress-gitlab-ci-stage-if-push-only-changes-readme-md). A better solution may be to simply manually include `[ci skip]` in the commit message of changes you want to skip CI on. Alternatively, you can use `git push -o ci.skip`, which works even if there is no commit message (such as when pushing a tag).
