-
Notifications
You must be signed in to change notification settings - Fork 12
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
IGN-10612 WIP DO NOT MERGE just for sharing code easily #57
Conversation
add test for jar presence, duplication, and sort order linting
Add `--foldJars` task option to preserve the old behavior by default, it's a breaking change and maybe the dups are useful to some. The option if passed does the scope folding and the sorting as before and another sort of folding for `CDG`-scoped jars, turning them into the `A`[ll]-scoped equivalent. Plus noticed that the tests fall into the `assertEquals` API trap where you think the argument order is `actual, expected` but it's really `expected, actual`. Completely nonintuitive and sort of asymmetric to other `assert*` APIs but when `assertEquals` fails having them in the wrong order makes things harder to troubleshoot.
Regex(DEPENDS).findAll(oneLineXml).toList().size, | ||
1 |
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.
This tricks everybody. Me. Others at IA. Probably everybody who has used it and the underlying JUnit call.
@@ -28,10 +28,11 @@ enum class IgnitionScope(val code: String) { | |||
GATEWAY_DESIGNER("DG"), | |||
GATEWAY_DESIGNER_VISION_CLIENT("CDG"), | |||
GATEWAY_VISION_CLIENT("CG"), | |||
ALL("A"), |
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.
Mirrors the same thing in the Ignition codebase.
) | ||
|
||
// Leave duplicate artifacts largely as-is, even if present in 2+ scopes. | ||
// This is legacy 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.
I regression tested this not only via unit test coverage in WriteModuleXmlTest.kt
, but by copying over that test class to a local master
branch along with the test helper utils.kt
and running it there.
The only thing that failed--as expected--was the new --foldJars
test.
So I'm pretty sure the logic that follows is equivalent to that before these PRs. I think the biggest difference is just refactoring to do pure transforms instead of nested forEach
es that have side effects (writing the output).
}.fold(mutableListOf<Pair<String, String>>()) { lst, (scope, jars) -> | ||
lst.apply { | ||
addAll( | ||
jars.map { jar -> jar to scope } |
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.
Essentially, flipflop keys and values while flattening the original values.
Served its purpose by contributing to the real PR, #53. |
Like the title says, don't merge me.
Just a way to ping-pong code back and forth on the actual PR, #53.