Comments (11)
You'll have to be more specific about what are your expectations. Could you elaborate a bit?
But from what I see above, that is expected behavior, when you push to my-repo, it triggers p1 (because there is no whitelist there), and then p1 triggers p2 because it is a material of p2. This is justified by the logic that if project in p2 somehow depends on p1 then a new build in p1 could break something in p2, hence you should build p2 with new p1. Is that clear enough?
from gocd-yaml-config-plugin.
You're right, my example is a bit off, so I'm going to provide a slightly different use case with more detail. I will need to test it in a short PoC though, to confirm that it's still a bug.
In my case my-repo
is a repository containing 3 projects:
pr1
as a library project (built by pipelinep1
).pr2
andpr3
as end-user projects, both depending onpr1
. (pr2
is built byp2
, andpr3
is built byp3
, configured similarly top2
. Both pipelines use the artifact generated byp1
.)
Now, If only pr3
changed, then I don't want to build pr2
, and if I only pr2
changed, I don't want to build pr3
. For that I can add a blacklist that ignores pr3
in p2
, and pr2
in p3
.
So in my case, I am sure that changes in p3
will not break p2
, and changes in p2
will not break p1
.
=> As promised, I will return with a confirmed example.
from gocd-yaml-config-plugin.
There is one minor bug that I am aware of. If you are introducing whitelist/blacklist change in current commit 123
, then this will not apply to builds triggered by it. Meaning 123
will trigger pipelines using old rules. But every next build should respect filters. Be aware of this when you confirm this bug.
from gocd-yaml-config-plugin.
Thanks. It still does not work the way I expect (tested multiple times). Here is my config:
pipelines:
p1:
materials:
my-repo:
git: some-url
auto_update: true
p2:
materials:
my-repo:
git: some-url
blacklist:
- pr3/**/*
auto_update: true
p1-as-upstream:
pipeline: p1
stage: some-stage
p3:
materials:
my-repo:
git: some-url
blacklist:
- pr2/**/*
auto_update: true
p1-as-upstream:
pipeline: p1
stage: some-stage
Then, if make a change inside pr3
, the p2
pipeline is still triggered. I also retested with pr2
changes, expecting no triggering of p3
, but it did. => Not OK.
If I removed p1-as-upstream
from the material config of p2
, then changes in pr3
did not trigger p2
, which is OK, but then I can't use artifacts from p1
.
=> It's like whitelists/blacklists are ignored when upstream pipelines are used.
from gocd-yaml-config-plugin.
OK, but does pr2 and pr3 get triggered only after p1 was built? If so then it is expected.
Above looks similar to first config you posted, but it has additional p3, which should not matter much. If you configure this with XML (via UI), I believe it would behave the same. The p2 or p3 are built because p1 was built and it is a dependency. You cannot "blacklist" triggers caused by one of dependency pipelines.
from gocd-yaml-config-plugin.
OK, but does pr2 and pr3 get triggered only after p1 was built?
Yes.
The p2 or p3 are built because p1 was built and it is a dependency.
This is unfortunate, as here I don't need an OR-condition for triggering, but an AND-condition (if that makes sense). It looks like that the material configuration is not as sophisticated...
If the XML behaves the same, then I conclude that the right support channel is the GoCD authors, not here. Thanks for your help though.
from gocd-yaml-config-plugin.
You should look into user forum - https://groups.google.com/forum/#!forum/go-cd
Above behavior is the CD-way because in your case, you have built a new library in p1, which is used by p2 and p3. The change in library could be breaking either of the end user projects, which is why both must be built.
It was disturbing to me at first too.
One way to stop all these builds from happening is to not have have an upstream pipeline and hard code released version of the library in the end projects. Each project is then built in independent pipeline. Builds only when you update the project or reference to library version.
from gocd-yaml-config-plugin.
I understand your argument, but in my case:
- Practically no changes in
pr2
orpr3
would build a different artifact inp1
, asp1
does not use those directories. The directories are practically completely isolated in that sense. - And putting all projects in the same repository was an important design decision, so that we don't have to manage hard-coded versions.
=> I'll contact the GoCD group.
from gocd-yaml-config-plugin.
If you don't want pr2
or pr3
changes to build p1
, then shouldn't you be adding those to the blacklist for p1
?
from gocd-yaml-config-plugin.
Thanks for the tip, @arvindsv, in fact you are right, but I tried it, and it's even worse: failed for the first 2 test cases below:
Test Case 1
- Change both
pr1
andpr3
in the same commit. - =>
p2
should not be built, but the rest.
Problem: all 3 builds were executed.
Test Case 2
- Do a change in
pr3
only. - =>
p1
&p2
should not be built, onlyp3
.
Problem: no builds were executed. (Incorrect => serious issue.)
Test Case 3
- Do a change in
pr1
only. - => All pipelines should be rebuilt.
Worked.
from gocd-yaml-config-plugin.
I contacted the developers directly, I think we should continue the conversation there (see the referenced issue).
from gocd-yaml-config-plugin.
Related Issues (20)
- RuntimeException when exporting certain pipelines HOT 3
- doesn't support branchblacklist/branchwhitelist attribute for git-feature-branch plugin HOT 1
- Move current GoCD templates into Yaml. Or find a way to reference global Yaml templates HOT 5
- Use pipeline parameters in the "approval" property HOT 3
- target_version 9 not supported in gocd 19.9.0 HOT 1
- Declaring a secret as an environement variable HOT 5
- Broken after update to 20.2 HOT 2
- is this plugin still maintained or not? HOT 1
- Pipeline Export always returns `format_version` = 3 HOT 1
- Private Github Repository material failing - Not recognizing username nor encrypted password attributes HOT 1
- Issue with export of pipeline with two materials without a name HOT 1
- Role access support for pipeline group via yaml config plugin HOT 4
- Support scm ref for config repo configuration
- Non editable parameters HOT 2
- Error exporting pipeline created using the UI. HOT 5
- Multibranch pipeline example request HOT 1
- Creating pipelines with request headers in yaml file config through API call seems wrong as it defaulted to null HOT 1
- Cannot refer elastic_profile_id to an environment variable. HOT 2
- nant_path label does not work HOT 2
- Duplicate Key error when using override feature from YAML HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gocd-yaml-config-plugin.