gocd: Same material on different pipelines: can't set different configuration.
- set up two pipelines A, B
- configure on pipeline A a material X as a git repo and make it poll for change.
- try to configure on pipeline B the same material X and this time configure to DO NOT pull for changes.
What you’ll get:
Material of type Git (git@xxx) is specified more than once in the configuration with different values for the autoUpdate attribute. All copies of the a material should have the same value for this attribute.
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Comments: 18 (9 by maintainers)
What’s the status of this? This is a pain in that, even if I want to turn off polling, I cant, due to this error message. It’s telling me both pipelines have to have the same attribute value for polling, therefore if I have two pipelines pointing to the same GitHub repo, I can’t change the value at all. Very inconvenient. Generally speaking there are too many rules baked into Go that end up painting you into a corner. I understand this is by design but the design needs to be rethought.
Sounds like an implementation issue, rather than a design decision.
Materials appear to be at a higher level than pipelines. So material polling is done before deciding which pipeline to trigger. This does not match what the UI suggests.
I would suggest that this is a valid “bug” - in terms of “the effects of the implematation are not ideal”. I dont think this should be closed.
From what I know of it, it was meant to be used with manual stages, and to reduce the effect of too many materials polling a repo (or many repos) too often.
I think the broader issue is that the material information (such as URL, branch, etc) should really be at a higher level (common across pipelines), but information such as whether to trigger, how often to poll, etc. should be at a pipeline level. The fact that those two are not separated is why all of this happens.
Yes, that would make sense. However, the way it is today, autoPolling is an attribute of the material, and doesn’t have any effect on the pipeline trigger. You are proposing changing it to mean something like: “triggerWhenChanged”.
Yes, this is not a bug. It’s intended behavior. As it says, “All copies of the a material should have the same value for this attribute”. Reason: In Go, unique materials are decided, and they’re polled or not polled based on the autoUpdate attribute. If the same material has both autoUpdate true and false, then it will need to be polled (for the true) and not polled (for the false). That doesn’t make sense.
If we were to somehow make this happen, pipeline B would trigger every time pipeline A found that material X has a new commit.
If you’re looking to turn off polling, so that pipeline B does not trigger automatically. If that’s the case, you can keep material X with polling turned on (in both) and make pipeline B’s first stage manual.