Dependency Management
When you have non-trivial dependency pipeline chains, you may have concerns about how dependant pipelines and materials interact. This section covers some Dependency Management concepts and how Go handles certain complex scenarios.
Propagate material revision throughout the dependency chain
If you have frequent material updates coupled with long running dependant pipelines sharing that same material, you may encounter situations where the revision that triggered the dependency chain is no longer the latest revision. Go keeps track of what revision triggered a dependency chain and ensures that the same version propagates throughout all members of that chain. This helps ensure that all artifacts generated as part of that build share a common revision.
Example
Consider the following dependency chain:
Legend
- SCM : Repository
- rev1, rev2 : Check-ins to the repository
- A : Pipeline for development build
- B : Pipeline for acceptance tests
How it works
- Code is checked in to SCM (rev1)
- Development build (A) is triggered by the check-in
- There is another check-in to SCM (rev2)
- Development build completes (with rev1) and triggers acceptance tests (B)
- Here's where dependency management comes in. Go is smart enough detect that rev1 originally triggered the build and ensures that the acceptance tests check-out that revision (rev1) and not the latest revision (rev2). In this situation, Go ensures that the appropriate version of acceptance tests are run against the appropriate version of the development build.
