Hello,
On Friday, 22 July 2016 15:32:36 UTC+5:30, Brett Cave wrote:
>
> 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.
>
>
>
Given that the pipeline BuildApp is dependent on the git repository 'repo'
and pipeline 'BuildCore', any *valid* change in either materials will
trigger 'BuildApp'. In this scenario, a valid change is any change to
'core/*'.
If you observe the build cause for BuildApp, when a commit is made in
'core/*', the build cause will only list the 'BuildCore' as the reason for
the trigger.
It may seem that it is a violation of the blacklist in BuildApp, but a
change in core/* is not the direct reason for BuildApp being triggered. It
is the expected behaviour.
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...
>
Since BuildApp is dependent on BuildCore and git repository 'repo', the
fan-in algorithm kicks in where it tries to find a compatible revision with
both the git material 'repo' and BuildCore. Since it cannot find that
BuildCore has been run with "app/foo", BuildApp will never get triggered.
This behaviour exists irrespective of the blacklist and whitelist feature.
And, because of the fan-in algorithm, the only valid change for BuildApp,
as mentioned above to be triggered is any change to 'core/*' only.
>
> 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....
>
Yes, that is correct.
The whitelist on the upstream pipeline "BuildCore" is respected even in
BuildApp because of the dependency. A workaround would be to remove the
whitelist in "BuildCore". However, keep in mind once the whitelist is
removed, the blacklist in downstream "BuildApp" will not be respected (that
is, blacklist on "BuildApp" is useless in this scenario to have) as any
change triggering "BuildCore" will end up triggering "BuildApp" anyway.
Thank You.
Varsha
--
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.
