Update Pipeline Notes authored by Slominski, Ryan's avatar Slominski, Ryan
...@@ -28,7 +28,7 @@ git push --tags -f ...@@ -28,7 +28,7 @@ git push --tags -f
**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. **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 # 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 that's also a catalog project, 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 - the catalog project release is special and won't let you release a new version of a catalog project with a reference to the version you are attempting to create. 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. I'd like to bump this default value to match the upcoming release. This won't work if you're using the release workflow to release a new version of the release workflow that's also a catalog project, 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 - the catalog project release is special and won't let you release a new version of a catalog project with a reference to the version you are attempting to create.
To get around this, we create new major version of the release workflow project first, then quickly follow up with yet another new release, but a minor 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: To get around this, we create new major version of the release workflow project first, then quickly follow up with yet another new release, but a minor 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:
...@@ -36,6 +36,8 @@ To get around this, we create new major version of the release workflow project ...@@ -36,6 +36,8 @@ To get around this, we create new major version of the release workflow project
- [on-tag-push](https://code.jlab.org/acc/iac/release-workflow/-/tree/main/templates/on-tag-push) - [on-tag-push](https://code.jlab.org/acc/iac/release-workflow/-/tree/main/templates/on-tag-push)
- [cxx-certified](https://code.jlab.org/acc/iac/release-workflow/-/tree/main/templates/cxx-certified) - [cxx-certified](https://code.jlab.org/acc/iac/release-workflow/-/tree/main/templates/cxx-certified)
So for example maybe we create on-file-push3, and on-file-push4. Keep maybe the most recent two available? Maybe this is more confusing...
# Auto DevOps # Auto DevOps
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. 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.
... ...
......