You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, when an artifact-source is configured for the pipeline of an umbrella repo, it is ensured that all configured subrepos have a successful pipeline run for the checked out commit. This ensures that e.g. image promotion to the target namespace works as expected.
What is currently not implemented is a similar check for the umbrella repo itself. For an umbrella repo this may not be crucial, but for the case where there is only a single repo, this feature is important. When there is no umbrella repo, merges must be done using fast-forward in order not to loose artifacts during promotion. Therefore, ODS Pipeline should check for this to avoid surprises.
As a consequence, Git merge operations which result in promotion must be done using fast-forward. I think this is fine, as that is the safest way to promote.
A further consequence is that the example project doc must be adjusted as there must be a pipeline run pushing artifacts into the Nexus dev repo, otherwise going to QA does not work. This is also fine as it enforces a good workflow (opening a PR to go to QA).
The text was updated successfully, but these errors were encountered:
Right now, when an
artifact-source
is configured for the pipeline of an umbrella repo, it is ensured that all configured subrepos have a successful pipeline run for the checked out commit. This ensures that e.g. image promotion to the target namespace works as expected.What is currently not implemented is a similar check for the umbrella repo itself. For an umbrella repo this may not be crucial, but for the case where there is only a single repo, this feature is important. When there is no umbrella repo, merges must be done using fast-forward in order not to loose artifacts during promotion. Therefore, ODS Pipeline should check for this to avoid surprises.
As a consequence, Git merge operations which result in promotion must be done using fast-forward. I think this is fine, as that is the safest way to promote.
A further consequence is that the example project doc must be adjusted as there must be a pipeline run pushing artifacts into the Nexus dev repo, otherwise going to QA does not work. This is also fine as it enforces a good workflow (opening a PR to go to QA).
The text was updated successfully, but these errors were encountered: