-
Notifications
You must be signed in to change notification settings - Fork 718
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a merge strategy extension point for the YAML config #1218
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of CasCGlobalConfig, should it not be SelfConfigurator?
plugin/src/main/java/io/jenkins/plugins/casc/CasCGlobalConfig.java
Outdated
Show resolved
Hide resolved
Looks great! |
Any more feedbacks are appreciated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a test for each merge strategy please? I think we’re good to go after that
without test case I have no idea how to change merge strategy 🤔 |
plugin/src/test/java/io/jenkins/plugins/casc/yaml/MergeStrategyTest.java
Show resolved
Hide resolved
plugin/src/test/java/io/jenkins/plugins/casc/OrderedMergeStrategyTest.java
Outdated
Show resolved
Hide resolved
@Casz Good advice. I do my best to try with this solution. |
The merge strategy should be set before starting to parse the YAML config file. I didn't find out how can I set |
@LinuxSuRen in the ConfigurationContext class you would add the merge strategy field configuration-as-code-plugin/plugin/src/main/java/io/jenkins/plugins/casc/ConfigurationContext.java Line 15 in 80e556e
This will be the first component configured thanks to: Lines 18 to 20 in 80e556e
configuration-as-code:
mergeStrategy: order
deprecated: warn |
@Casz If there're two config files which all contain |
@LinuxSuRen then they are also asking for trouble, let's assume that people won't conflict on it. |
import java.util.Iterator; | ||
|
||
@Extension | ||
public class DefaultMergeStrategy implements MergeStrategy { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Default
is a terrible name it does not describe the merge behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
StrategicMerge? It’s the name kustomize used for ‘smart’ merge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It just throws an exception when there's conflict exists.
What about IrreconcilableMergeStrategy
?
Another problem is that it looks like I can get the right value of mergeStrategy before all the config files were loaded if I put mergeStrategy into |
27c231f
to
b34e7a9
Compare
I messed up the git commit history before. I wish we can push it forward. |
@LinuxSuRen are you able to implement this? |
Yes, but I think the merge strategy should be loaded before the YAML file is actually parsed. |
@LinuxSuRen would be great to land this, do you mind fixing the conflicts. |
@jetersen Sorry that I missing your message here. I'll fix them in recent days. |
/** | ||
* Load configuration-as-code model from a set of Yaml sources, merging documents | ||
*/ | ||
public static Mapping loadFrom(List<YamlSource> sources) throws ConfiguratorException { | ||
public static Mapping loadFrom(List<YamlSource> sources, MergeStrategy mergeStrategy) throws ConfiguratorException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems unnecessary to pass merge strategy here. Properly simpler to call MergeStrategyFactory.getMergeStrategy()
inside the merge method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I think it would be best to move the call to ConfigurationContext constructor and store the merge strategy in the context
Are we still interested in this pull request? |
See it from here. I also put a link on the README file. |
docs/features/mergeStrategy.md
Outdated
|
||
## Support strategies | ||
|
||
* [IrreconcilableMergeStrategy]((../../plugin/src/main/java/io/jenkins/plugins/casc/yaml/IrreconcilableMergeStrategy.java)) (default) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we just match the class name to the subtracting mergestrategy?
so the class should be called ErrorOnConflictMergeStrategy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure.
docs/features/mergeStrategy.md
Outdated
It's possible to load multiple config files. CasC can load YAML files from a directory. | ||
And it's convenient to maintain if we split different parts of Jenkins into multiple files. | ||
|
||
## Support strategies |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Support strategies | |
## Supported strategies |
docs/features/mergeStrategy.md
Outdated
|
||
* [IrreconcilableMergeStrategy]((../../plugin/src/main/java/io/jenkins/plugins/casc/yaml/IrreconcilableMergeStrategy.java)) (default) | ||
* The strategy name is `errorOnConflict`. | ||
* Throw an exception if there's a conflict exist in multiple YAML files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Throw an exception if there's a conflict exist in multiple YAML files. | |
* Throws an exception if there's a conflict in multiple YAML files. |
docs/features/mergeStrategy.md
Outdated
You can provide two YAML config files. They can be system and user config files. Then allow users to change the users' part. | ||
So, the users' config file can override the system one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe?
You can provide two YAML config files. They can be system and user config files. Then allow users to change the users' part. | |
So, the users' config file can override the system one. | |
You can provide two YAML config files. They can be system and user config files. Then allow users to change their file and override the system configuration. |
Co-authored-by: Joseph Petersen <[email protected]>
Code looks good from reading it, when I get a chance I'd like to try this out myself locally, and then merge if all is fine. (That doesn't stop another maintainer from merging this though) |
Hi all reviewers, I really hope to see it merged quickly. |
You could try it out and provide feedback. I’m away currently, back tomorrow, but I’ve got a backlog to work through, I hope to get to it soon |
hi @timja , I've tested against this feature. Everything is ok to me. |
I tested 4 scenarios, I think the merging needs to be a bit smarter, I was especially surprised that systemMessage override ❌# 1.yaml
jenkins:
systemMessage: "hello1"
# 2.yaml
jenkins:
systemMessage: "hello2" expected: jenkins:
systemMessage: "hello2" actual jenkins:
systemMessage: "hello1" simple globalNodeProperties override ✔️# 1.yaml
jenkins:
globalNodeProperties:
- envVars:
env:
- key: VARIABLE1
value: foo
# 2.yaml
jenkins:
globalNodeProperties:
- envVars:
env:
- key: VARIABLE2
value: bar expected: jenkins:
globalNodeProperties:
- envVars:
env:
- key: VARIABLE1
value: foo
- key: VARIABLE2
value: bar actual jenkins:
globalNodeProperties:
- envVars:
env:
- key: VARIABLE1
value: foo
- key: VARIABLE2
value: bar globalNodeProperties override with another sequence object ❌# 1.yaml
jenkins:
systemMessage: normal
globalNodeProperties:
- envVars:
env:
- key: VARIABLE1
value: foo
agentProtocols:
- "jnlp1"
# 2.yaml
jenkins:
globalNodeProperties:
- envVars:
env:
- key: VARIABLE2
value: bar
agentProtocols:
- "jnlp2"
expected: jenkins:
globalNodeProperties:
- envVars:
env:
- key: VARIABLE1
value: foo
- key: VARIABLE2
value: bar actual jenkins:
globalNodeProperties:
- envVars:
env:
- key: VARIABLE2
value: bar build discarder override ✔️# 1.yaml
unclassified:
buildDiscarders:
configuredBuildDiscarders:
- "jobBuildDiscarder"
# 2.yaml
unclassified:
buildDiscarders:
configuredBuildDiscarders:
- simpleBuildDiscarder:
discarder:
logRotator:
daysToKeepStr: "7"
numToKeepStr: "10" expected: unclassified:
buildDiscarders:
configuredBuildDiscarders:
- "jobBuildDiscarder"
- simpleBuildDiscarder:
discarder:
logRotator:
daysToKeepStr: "7"
numToKeepStr: "10" actual unclassified:
buildDiscarders:
configuredBuildDiscarders:
- "jobBuildDiscarder"
- simpleBuildDiscarder:
discarder:
logRotator:
daysToKeepStr: "7"
numToKeepStr: "10" |
Retested all,
I assume agentProtocols change is getting silently rejected which is fine, but the lists should be being merged so I get: jenkins:
globalNodeProperties:
- envVars:
env:
- key: VARIABLE1
value: foo
- key: VARIABLE2
value: bar but I'm just getting: globalNodeProperties:
- envVars:
env:
- key: "VARIABLE2"
value: "bar" |
I found it. I'm still working on it. But I think it might be more complicated. Let's assume that there are two I'm not sure if I explain it well. But I'm looking forward more feedback on this. |
Thanks to all contributors help me to review this PR. I'm looking forward to the release of this plugin. I'm not sure if @timja has the release permission. Please help me with it if you think it's ok. |
it's in progress |
Hello, I have a suggestion to improve the documentation for the merge strategy. As a Jenkins administrator, I find the current information less helpful, especially for those who are not Java developers. It would be great if we could make the documentation clearer and more user-friendly, catering to the needs of all administrators, regardless of their programming background. Thank you for considering this improvement. Best regards, |
Your checklist for this pull request
fix #1194
🚨 Please review the guidelines for contributing to this repository.