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
[WFLY-19267] Support running the standard WildFly testsuite against installations provisioned with the 'latest standard channels' #17838
Conversation
…nstallations provisioned with the 'latest standard channels'
<configuration> | ||
<channels> | ||
<channel> | ||
<manifest> | ||
<groupId>${channels.maven.groupId}</groupId> | ||
<artifactId>wildfly-ee</artifactId> | ||
</manifest> | ||
</channel> | ||
<channel> | ||
<manifest> | ||
<groupId>${channels.maven.groupId}</groupId> | ||
<artifactId>wildfly</artifactId> | ||
</manifest> | ||
</channel> | ||
</channels> | ||
</configuration> |
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.
There is no wildfly-preview channel attached here, so I'm not sure how the expected channels would be injected when this plugin configuration is merged with the one on preview/build.
Would it become an issue?
I guess the same is applied to the ee-build. The plugin configuration merged will attach wildfly-ee and wildfly channels. Is that expected for an ee-build?
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.
In both cases, yes the limitations you point out are expected. This profile as is will not work for testing WFP or for testing wildfly-ee by itself.
https://issues.redhat.com/browse/WFLY-19268 will replace this, but it is out of scope for this task, which is really just about having an upstream variant of an urgent downstream change that tests a combination of these two FPs. Neither wildfly-ee-only testing nor wildfly-preview are relevant to the downstream change.
https://issues.redhat.com/browse/WFLY-19268 will take advantage of the greater flexibility we have in wildfly-maven-plugin 5, which is not used downstream.
Thanks @yersan. I'll be following up with another PR related to this that deals with bootable jar testing. |
https://issues.redhat.com/browse/WFLY-19267
This builds on #17799, which deals with a similar use case. The WFLY-19214 approach there is more flexible but more verbose in cases where the latest version of standard channels manifests are wanted.
<--- THIS SECTION IS AUTOMATICALLY GENERATED BY WILDFLY GITHUB BOT. ANY MANUAL CHANGES WILL BE LOST. --->
<--- END OF WILDFLY GITHUB BOT REPORT --->
More information about the wildfly-bot[bot]