The GitHub Actions job "Coverage" on grails-intellij-plugin.git/feature/grails-view-nodes has failed. Run started by GitHub user amondel2 (triggered by amondel2).
Head commit for run: b19e2035bc8d6895ab73a97585d6f0ce001f1ef1 / aaron <[email protected]> Give Grails asset, translation, migration and test-root folders their own nodes The Grails project view pane had no node for several directories that a generated app actually has, so they all collapsed into a single "Other sources" entry. This gives them dedicated nodes, and stops the nodes that now own them from also claiming their contents. New top-level nodes, each carrying the real directory as its location: grails-app/i18n Translations grails-app/assets/stylesheets Stylesheets grails-app/assets/images Images grails-app/assets/javascripts JavaScripts grails-app/utils Utils grails-app/migrations Migrations grails-app/init Initialization grails-app/conf Configuration Rendered directory order is Images, JavaScripts, Stylesheets, Views, Migrations, Translations, Utils, Initialization, Configuration, Other sources, then src and the test roots. Services now sorts above Controllers. The Grails 3+ test source roots (src/test, src/integration-test, src/functional-test) are lifted out of the src node and titled with the Grails 2 phase labels, Tests:unit, Tests:integration and Tests:functional, each with its real path as the location string. Test roots are discovered rather than matched against a fixed name list, so a project's own testPhases entries are lifted too; src/main is never lifted. Because those nodes own their directories now, the Other sources and src nodes must refuse to claim files beneath them, or Reveal in Project View expands the node, finds nothing and dead-ends. PsiDirectoryNode.contains() applies a filter to the file itself only, never to its parent, so both nodes walk the file's ancestors to decide. That consistency is structural, not incidental: GrailsViewItems holds the single definition of a directory being hidden from Other sources, and both the filter and contains() consult it. One predicate means the two cannot drift apart again, which is what the previous two implementations did. Two corrections to Grails facts the code and docs had wrong: - The kebab-case test roots are not a Grails 7 convention. They are the Grails 3+ roots; IntegrationTestGradlePlugin has used sourceFolderName = 'src/integration-test' since Grails 3, and no Grails version generates camelCase test roots. - grails-forge does not generate grails-app/utils. GrailsBase creates no grails-app/utils at all; the utils/.gitkeep comes from the legacy grails-profiles/web/skeleton. Conversely init/ IS generated, by grails-forge's GrailsApplication feature, which writes grails-app/init/{packagePath}/Application.groovy and BootStrap.groovy. Node weights are now declared as literals in NodeWeights, including INTERCEPTORS_FOLDER and INIT_FOLDER, which were previously computed expressions at their call sites and so invisible to NodeWeightsTest. Tests assert rendered output rather than constant values: the ordering tests sort the real createNodes() output through GrailsNodeComparator, so they catch a provider that stops emitting a node. Labelling a node needed a platform detail that no unit test could have caught. PsiDirectoryNode builds the tree label from PresentationData's coloured fragments, not from presentableText, and fills those fragments with the directory's qualified path; setting presentableText therefore changed nothing the renderer draws. GrailsPsiDirectoryNode now clears and re-adds the fragments in postprocess, the only hook that runs after the platform has written the label. The rendering tests go through update() for the same reason, and AGENTS.md records both traps under "Project view gotchas". Unrelated to the above, README.md's Requirements section said the plugin "will not load in Community", contradicting its own intro and CE-SUPPORT.md. It described the pre-content-module arrangement. Corrected to describe the current mechanism. Report URL: https://github.com/apache/grails-intellij-plugin/actions/runs/37413456587 With regards, GitHub Actions via GitBox
