Hi Go users and devs,
The new 16.6 release is great, especially the whitelist feature which I
never implemented correctly initially, but seems to be working now.
However, I believe I may have come across a bug - could you confirm?
The scenario:
- A git repository "repo" with "core" and "app" root paths.
- A "BuildCore" pipeline that uses "repo" with a whitelist on "core/*" -
triggers automatically
- A "BuildApp" pipeline that uses "repo" with a blacklist on "core/*"
and an upstream pipeline dependency / material on "BuildCore" - triggers
automatically
The bug is that it seems like Go traces its upstream pipelines' materials
and if a common material is found, the downstream pipeline will wait for
the upstream pipeline to finish before triggering.
In this scenario, if a commit is pushed to "app/foo", both BuildCore and
BuildApp detect the new "repo" material. BuildCore doesn't trigger because
only "core" is in its whitelist ("app/foo" is blacklisted). BuildApp finds
the change, but doesn't trigger because it sees that BuildCore also uses
the "repo" material and wants to wait for it to trigger and finish - it
doesn't realize that BuildCore will not trigger due to the blacklist -
BuildApp never triggers automatically. I'd imagine that it's only when I
push to "core/bar" that BuildCore would trigger and that would then kick
off BuildApp...
I now either need to remove the black / white lists and build BuildCore for
all commits or trigger manually. I'd imagine a solution to this is that
BuildApp should not only check if "repo" is an upstream of "BuildCore" but
should also ensure that the new "repo" material is not blacklisted there....
Is this a valid bug? Is there any workaround for this?
Cheers,
Brett
--
You received this message because you are subscribed to the Google Groups
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
