[JBoss JIRA] (WFLY-5793) Allow selective CI builds
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/WFLY-5793?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on WFLY-5793:
------------------------------------
I was also thinking that this could be applied to updates to *.txt, *.sh and *.bat (my understanding is there is no test cases associated with the latter two). Of course this would be applicable to the core repo as well.
I'm not familiar with the WFLY CI setup, so I don't have any real grounding on how difficult/time consuming such an enhancement would be. You could be right that the amount of resources saved is not worth the time cost.
> Allow selective CI builds
> -------------------------
>
> Key: WFLY-5793
> URL: https://issues.jboss.org/browse/WFLY-5793
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Ryan Emerson
> Assignee: Tomaz Cerar
>
> Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md).
> A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (WFBUILD-14) Conflicting feature pack dependency versions should not be allowed
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-14?page=com.atlassian.jira.plugin... ]
Thomas Diesler updated WFBUILD-14:
----------------------------------
Description:
There was a brief discussion about this on the WildFly dev mailing list so I'm capturing the problem here as well.
Consider the following.
Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
{code:xml}
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
</dependencies>
{code}
Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
{code:xml}
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
<artifact name="org.foo:feature-pack-A" />
</dependencies>
{code}
The result is that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions
At the moment the plugins allow this scenario, which can lead to all sorts of horrors when using the server-provisioning plugin to provision an app server.
CrossRef: https://github.com/wildfly-extras/fuse-patch/issues/101
was:
There was a brief discussion about this on the WildFly dev mailing list so I'm capturing the problem here as well.
Consider the following.
Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
</dependencies>
Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
<artifact name="org.foo:feature-pack-A" />
</dependencies>
The result is that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions
At the moment the plugins allow this scenario, which can lead to all sorts of horrors when using the server-provisioning plugin to provision an app server.
> Conflicting feature pack dependency versions should not be allowed
> ------------------------------------------------------------------
>
> Key: WFBUILD-14
> URL: https://issues.jboss.org/browse/WFBUILD-14
> Project: WildFly Build Tools
> Issue Type: Bug
> Reporter: James Netherton
> Assignee: Stuart Douglas
>
> There was a brief discussion about this on the WildFly dev mailing list so I'm capturing the problem here as well.
> Consider the following.
> Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> </dependencies>
> {code}
> Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
> <artifact name="org.foo:feature-pack-A" />
> </dependencies>
> {code}
> The result is that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions
> At the moment the plugins allow this scenario, which can lead to all sorts of horrors when using the server-provisioning plugin to provision an app server.
> CrossRef: https://github.com/wildfly-extras/fuse-patch/issues/101
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (WFLY-5796) Topic Subsriber does only get messages produced on node 2 after failover and failback of node 1
by Michal Sudra (JIRA)
Michal Sudra created WFLY-5796:
----------------------------------
Summary: Topic Subsriber does only get messages produced on node 2 after failover and failback of node 1
Key: WFLY-5796
URL: https://issues.jboss.org/browse/WFLY-5796
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 10.0.0.CR4
Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
Reporter: Michal Sudra
Assignee: Jeff Mesnil
Attachments: domain.xml, host.xml
Client (Topic Subscriber) is connected to a 2 node symmetrical colocated life backup cluster receiving messages produced on any node (random).
Observed behavior:
When node 1 is shut down (failover to node 2). -> Client is automatically failing over to node 2 and is continuing to consume messages produced on node 2.
Then node 1 is restarted (failback to node 1). From now on the client is only receiving messages produced on node 2, not messages produced on node 1.
When node 2 is shut down (failover to node 1). -> Client is automatically failing over to node 1 and is continuing to consume messages produced on node 1.
Then node 2 is restarted (failback to node 2). From now on the client is only receiving messages produced on node 1, not messages produced on node 2.
Expected behavior:
The client should at any time receive all messages regardless on which node the message is produced.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (WFLY-5793) Allow selective CI builds
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5793?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5793:
--------------------------------------
Can you list more real examples apart from updating README.md? My guess would be that the percentage of such pull requests is so little that it's not worth pursuing.
> Allow selective CI builds
> -------------------------
>
> Key: WFLY-5793
> URL: https://issues.jboss.org/browse/WFLY-5793
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Ryan Emerson
> Assignee: Tomaz Cerar
>
> Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md).
> A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (WFLY-5795) HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
by Michal Sudra (JIRA)
Michal Sudra created WFLY-5795:
----------------------------------
Summary: HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
Key: WFLY-5795
URL: https://issues.jboss.org/browse/WFLY-5795
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 10.0.0.CR4
Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
Reporter: Michal Sudra
Assignee: Jeff Mesnil
Priority: Critical
Attachments: ClusteredTopicTest.java, domain.xml, host.xml
Test Client is producing 10 messages on topic on node 1 and 2 consumers connected to node 1 and the other to node 2 are then consuming the messages.
Expectation: Every consumer receives 10 Messages.
Result of test: Consumer connected to node 1 is only getting every second message. Consumer connected to node 2 is receiving all 10 messages:
Output of test program:
Sent message: This is text message 0
Sent message: This is text message 1
Sent message: This is text message 2
Sent message: This is text message 3
Sent message: This is text message 4
Sent message: This is text message 5
Sent message: This is text message 6
Sent message: This is text message 7
Sent message: This is text message 8
Sent message: This is text message 9
0 Recieved message: This is text message 0 from node 0 from java:/jms/topic/ClusterStateTopic
1 Recieved message: This is text message 2 from node 0 from java:/jms/topic/ClusterStateTopic
2 Recieved message: This is text message 4 from node 0 from java:/jms/topic/ClusterStateTopic
3 Recieved message: This is text message 6 from node 0 from java:/jms/topic/ClusterStateTopic
4 Recieved message: This is text message 8 from node 0 from java:/jms/topic/ClusterStateTopic
5 error receiving message from node 0
6 error receiving message from node 0
7 error receiving message from node 0
8 error receiving message from node 0
9 error receiving message from node 0
0 Recieved message: This is text message 0 from node 1 from java:/jms/topic/ClusterStateTopic
1 Recieved message: This is text message 1 from node 1 from java:/jms/topic/ClusterStateTopic
2 Recieved message: This is text message 2 from node 1 from java:/jms/topic/ClusterStateTopic
3 Recieved message: This is text message 3 from node 1 from java:/jms/topic/ClusterStateTopic
4 Recieved message: This is text message 4 from node 1 from java:/jms/topic/ClusterStateTopic
5 Recieved message: This is text message 5 from node 1 from java:/jms/topic/ClusterStateTopic
6 Recieved message: This is text message 6 from node 1 from java:/jms/topic/ClusterStateTopic
7 Recieved message: This is text message 7 from node 1 from java:/jms/topic/ClusterStateTopic
8 Recieved message: This is text message 8 from node 1 from java:/jms/topic/ClusterStateTopic
9 Recieved message: This is text message 9 from node 1 from java:/jms/topic/ClusterStateTopic
The test program is added and the 2 node names are given as parameters for main.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (WFLY-5793) Allow selective CI builds
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5793?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-5793:
---------------------------------
Assignee: Tomaz Cerar (was: Jason Greene)
> Allow selective CI builds
> -------------------------
>
> Key: WFLY-5793
> URL: https://issues.jboss.org/browse/WFLY-5793
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Ryan Emerson
> Assignee: Tomaz Cerar
>
> Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md).
> A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (WFLY-5793) Allow selective CI builds
by Ryan Emerson (JIRA)
Ryan Emerson created WFLY-5793:
----------------------------------
Summary: Allow selective CI builds
Key: WFLY-5793
URL: https://issues.jboss.org/browse/WFLY-5793
Project: WildFly
Issue Type: Enhancement
Reporter: Ryan Emerson
Assignee: Jason Greene
Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md).
A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (WFLY-5166) LookupTestCase can not create session factory with secman
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-5166?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf closed WFLY-5166.
-------------------------------
Resolution: Migrated to another ITS
> LookupTestCase can not create session factory with secman
> ---------------------------------------------------------
>
> Key: WFLY-5166
> URL: https://issues.jboss.org/browse/WFLY-5166
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Ivo Studensky
>
> *Description of problem:*
> org.jboss.as.test.integration.ee.remotelookup.LookupTestCase can not create session factory with secman. Test runs in "basic-integration-default-full.surefire" execution of basic profile.
> *How reproducible:*
> Always with security manager
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dtest=LookupTestCase -Dsecurity.manager -Dts.basic
> *Actual results:*
> {noformat}
> javax.jms.JMSException: Failed to create session factory
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:921)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:726)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:170)
> at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.lookupConnectionFactory(LookupTestCase.java:81)
> at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.testServerLocalLookup(LookupTestCase.java:66)
> {noformat}
> *Expected results:*
> No errors on output
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months