Replies: 1 comment
-
I had a read through the (Concourse) source, but could see no easy way to solve this problem with the present-day implementation. What if Would it be reasonable to offer the bypass as an optional attribute on the step?
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello,
I'm looking to set up a multi-branch workflow (on Git) not unlike that described in Tracking Branches. Pipelines should appear and disappear (or be archived) with the appearance and disappearance of branch heads. Ephemeral pipelines should update with each new version from the
git
resource -- prior to execution. As perhaps one additional complication, my child pipeline definitions reside in the spatial git repo.In other words, I'm looking to emulate the sort of behaviour that most Git-native CI systems offer with their in-repo pipeline configurations.
I have most of the pieces in place, but have stumbled on what would appear to be an intractable problem:
If the child pipeline is configured without
set_pipeline: self
, most things work -- except the child pipeline often (always?) executes with a pipeline configuration from a previous branch tip revision. The child pipeline is executed before its parent is given an opportunity toset_pipeline: child
.If the child pipeline is configured with
set_pipeline: self
, the problem above goes away, but is replaced with a new problem.set_pipeline: self
overwrites the parent reference on the pipeline, disconnecting the child from its original parent pipeline. This breaks pipeline garbage collection. When the branch head is eventually removed from the git repository, the child pipeline is not automatically removed (or archived). (To add insult to injury, a new build is scheduled on the child pipeline, which fails because the ref is no longer available.)I don't expect this problem is specific to multi-branch workflows. Any workflow where a parent->child relationship exists simultaneous with a
set_pipeline: self
(in the child) would probably do it. Though multi-branch workflows are perhaps more likely to spawn ephemeral pipelines, so the non-functional pipeline GC is more noticeable.Pipelines below. I am using Concourse v7.9.0. Is it possible to solve both of these problems simultaneously? Thanks!
There are three pipelines. The grandparent and parent reside in something like a 'Concourse bootstrap' repository. The child resides in a separate spatial project repository.
grandparent:
parent (
bootstrap/plumb/project-branch.yml
from above):child (
project/dist/concourse/pipeline.yml
from above):Beta Was this translation helpful? Give feedback.
All reactions