[JBoss JIRA] (JBTM-1895) restat-bridge:jar is not uploaded during release
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1895?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1895:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/410
> restat-bridge:jar is not uploaded during release
> ------------------------------------------------
>
> Key: JBTM-1895
> URL: https://issues.jboss.org/browse/JBTM-1895
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M5
>
>
> Marking which jars are uploaded to Nexus during release is a two step process (unfortunately). You need to add both of the following bits of XML to the pom associated with the jar.
> The following ensures that the artefact is installed in the local maven repo when we do CI. This allows us to test the same set of artefacts that will be released. We needed this as we were finding out too late (after release) that we had dependencies on internal artefacts that we did not want to release.
> {code}
> <profile>
> <id>release</id>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-install-plugin</artifactId>
> <executions>
> <execution>
> <id>default-install</id>
> <phase>install</phase>
> </execution>
> </executions>
> <inherited>false</inherited>
> </plugin>
> </plugins>
> </build>
> </profile>
> {code}
> The following ensures that the artefact is uploaded to Nexus when the release is done.
> {code}
> <plugin>
> <inherited>false</inherited>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-deploy-plugin</artifactId>
> <configuration>
> <skip>false</skip>
> </configuration>
> </plugin>
> {code}
> We could probably move both plugins into the release profile as this is now enabled in build-release-packages.xml when we do the release.
> I've checked the current code base for all occurrences of this error and no more exist. In-case you are interested, I used the following, rather crude script:
> {code}
> #!/bin/bash
> RELEASE_PROFILES=$(find . -name pom.xml | xargs grep "<id>release</id>" | awk -F ':' '{ print $1 }')
> for POM in $RELEASE_PROFILES; do
> FOUND=$(grep maven-deploy-plugin $POM)
> if [ "$FOUND" == "" ]; then
> echo $POM
> fi
> done
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1895) restat-bridge:jar is not uploaded during release
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1895?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1895:
--------------------------------
Description:
Marking which jars are uploaded to Nexus during release is a two step process (unfortunately). You need to add both of the following bits of XML to the pom associated with the jar.
The following ensures that the artefact is installed in the local maven repo when we do CI. This allows us to test the same set of artefacts that will be released. We needed this as we were finding out too late (after release) that we had dependencies on internal artefacts that we did not want to release.
{code}
<profile>
<id>release</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>default-install</id>
<phase>install</phase>
</execution>
</executions>
<inherited>false</inherited>
</plugin>
</plugins>
</build>
</profile>
{code}
The following ensures that the artefact is uploaded to Nexus when the release is done.
{code}
<plugin>
<inherited>false</inherited>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>false</skip>
</configuration>
</plugin>
{code}
We could probably move both plugins into the release profile as this is now enabled in build-release-packages.xml when we do the release.
I've checked the current code base for all occurrences of this error and no more exist. In-case you are interested, I used the following, rather crude script:
{code}
#!/bin/bash
RELEASE_PROFILES=$(find . -name pom.xml | xargs grep "<id>release</id>" | awk -F ':' '{ print $1 }')
for POM in $RELEASE_PROFILES; do
FOUND=$(grep maven-deploy-plugin $POM)
if [ "$FOUND" == "" ]; then
echo $POM
fi
done
{code}
was:
Marking which jars are uploaded to Nexus during release is a two step process (unfortunately). You need to add both of the following bits of XML to the pom associated with the jar.
{code}
#!/bin/bash
RELEASE_PROFILES=$(find . -name pom.xml | xargs grep "<id>release</id>" | awk -F ':' '{ print $1 }')
for POM in $RELEASE_PROFILES; do
FOUND=$(grep maven-deploy-plugin $POM)
if [ "$FOUND" == "" ]; then
echo $POM
fi
done
{code}
> restat-bridge:jar is not uploaded during release
> ------------------------------------------------
>
> Key: JBTM-1895
> URL: https://issues.jboss.org/browse/JBTM-1895
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M5
>
>
> Marking which jars are uploaded to Nexus during release is a two step process (unfortunately). You need to add both of the following bits of XML to the pom associated with the jar.
> The following ensures that the artefact is installed in the local maven repo when we do CI. This allows us to test the same set of artefacts that will be released. We needed this as we were finding out too late (after release) that we had dependencies on internal artefacts that we did not want to release.
> {code}
> <profile>
> <id>release</id>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-install-plugin</artifactId>
> <executions>
> <execution>
> <id>default-install</id>
> <phase>install</phase>
> </execution>
> </executions>
> <inherited>false</inherited>
> </plugin>
> </plugins>
> </build>
> </profile>
> {code}
> The following ensures that the artefact is uploaded to Nexus when the release is done.
> {code}
> <plugin>
> <inherited>false</inherited>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-deploy-plugin</artifactId>
> <configuration>
> <skip>false</skip>
> </configuration>
> </plugin>
> {code}
> We could probably move both plugins into the release profile as this is now enabled in build-release-packages.xml when we do the release.
> I've checked the current code base for all occurrences of this error and no more exist. In-case you are interested, I used the following, rather crude script:
> {code}
> #!/bin/bash
> RELEASE_PROFILES=$(find . -name pom.xml | xargs grep "<id>release</id>" | awk -F ':' '{ print $1 }')
> for POM in $RELEASE_PROFILES; do
> FOUND=$(grep maven-deploy-plugin $POM)
> if [ "$FOUND" == "" ]; then
> echo $POM
> fi
> done
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1895) restat-bridge:jar is not uploaded during release.
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1895?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1895:
--------------------------------
Description:
Marking which jars are uploaded to Nexus during release is a two step process (unfortunately). You need to add both of the following bits of XML to the pom associated with the jar.
{code}
#!/bin/bash
RELEASE_PROFILES=$(find . -name pom.xml | xargs grep "<id>release</id>" | awk -F ':' '{ print $1 }')
for POM in $RELEASE_PROFILES; do
FOUND=$(grep maven-deploy-plugin $POM)
if [ "$FOUND" == "" ]; then
echo $POM
fi
done
{code}
> restat-bridge:jar is not uploaded during release.
> -------------------------------------------------
>
> Key: JBTM-1895
> URL: https://issues.jboss.org/browse/JBTM-1895
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M5
>
>
> Marking which jars are uploaded to Nexus during release is a two step process (unfortunately). You need to add both of the following bits of XML to the pom associated with the jar.
> {code}
> #!/bin/bash
> RELEASE_PROFILES=$(find . -name pom.xml | xargs grep "<id>release</id>" | awk -F ':' '{ print $1 }')
> for POM in $RELEASE_PROFILES; do
> FOUND=$(grep maven-deploy-plugin $POM)
> if [ "$FOUND" == "" ]; then
> echo $POM
> fi
> done
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1895) restat-bridge:jar is not uploaded during release
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1895?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1895:
--------------------------------
Summary: restat-bridge:jar is not uploaded during release (was: restat-bridge:jar is not uploaded during release.)
> restat-bridge:jar is not uploaded during release
> ------------------------------------------------
>
> Key: JBTM-1895
> URL: https://issues.jboss.org/browse/JBTM-1895
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M5
>
>
> Marking which jars are uploaded to Nexus during release is a two step process (unfortunately). You need to add both of the following bits of XML to the pom associated with the jar.
> {code}
> #!/bin/bash
> RELEASE_PROFILES=$(find . -name pom.xml | xargs grep "<id>release</id>" | awk -F ':' '{ print $1 }')
> for POM in $RELEASE_PROFILES; do
> FOUND=$(grep maven-deploy-plugin $POM)
> if [ "$FOUND" == "" ]; then
> echo $POM
> fi
> done
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1460) TXBridge test hangs when Arquillian starts the container
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1460?page=com.atlassian.jira.plugin.... ]
Paul Robinson resolved JBTM-1460.
---------------------------------
Fix Version/s: 5.0.0.M5
(was: 5.0.0.Final)
Resolution: Out of Date
We've not seen this again in nearly 7 months.
> TXBridge test hangs when Arquillian starts the container
> --------------------------------------------------------
>
> Key: JBTM-1460
> URL: https://issues.jboss.org/browse/JBTM-1460
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, TxBridge
> Environment: AS7 master as of 2013-02-05
> Arquillian core: 1.0.0.Final
> Arquillian osgi: 1.0.2.Final
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M5
>
> Attachments: client.log, server.log
>
>
> See: 172.17.131.2/job/btny-pulls-narayana/345/ where the job has hung for about 16hrs.
> From looking at the stack trace in client.log (attached):
> {code}
> at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:107)
> at org.jboss.jbossts.txbridge.tests.inbound.junit.InboundBasicTests.setUp(InboundBasicTests.java:75)
> {code}
> The hang is happening on this line:
> {code}
> controller.start(CONTAINER);
> {code}
> Which is starting the container 'jboss', which is described in the arquillian.xml as:
> {code}
> <container qualifier="jboss" default="true" mode="manual">
> <configuration>
> <property name="javaVmArguments">${server.jvm.args}</property>
> <property name="serverConfig">standalone-xts.xml</property>
> <property name="managementAddress">${node.address}</property>
> </configuration>
> </container>
> {code}
> From looking at server.log (attached) it looks like the server has started and deployed the deployments:
> First of two deployments:
> {code}
> 18:36:32,013 INFO [org.jboss.as.server] (management-handler-thread - 4) JBAS018559: Deployed "txbridge-inbound-tests-service.war" (runtime-name : "txbridge-inbound-tests-service.war")
> {code}
> Second of two deployments:
> {code}
> 18:36:32,975 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "txbridge-inbound-tests-client.war" (runtime-name : "txbridge-inbound-tests-client.war")
> {code}
> Notice that the output above is that last line of output on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBTM-1808) Investigate why QA tests take 5hrs to run per ORB
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1808?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1808:
-------------------------------------
Maybe this isn't worth the bother? How about we split the job up into 5 1hr pieces and defer this task until we are in a position where we are using too much CI time?
> Investigate why QA tests take 5hrs to run per ORB
> -------------------------------------------------
>
> Key: JBTM-1808
> URL: https://issues.jboss.org/browse/JBTM-1808
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System, Testing
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> Our full build and test suite takes 12hrs to run. This is causing severe strain on our CI resources.
> Out of this 12hrs, 10hrs is consumed by the QA test suite (5hrs per orb). It would be good to understand where this time is spent so that we can hopefully bring the test time down.
> If there is no reasonable way to bring the timing down, we could chop the tests up into 5 groups (per orb) taking 1hr each. This would make better use of our CI cluster during quiet periods, but will not eleviate the load during busy periods. It is also likely to be a poor usage of resources as I suspect the CPU utilisation of each job will be low.
> I suspect the problem is that we have a lot of Thread.sleeps in the tests. Therefore we are likely to see long tests with low resource (CPU) utilisation. However, further investigation is required to understand where the time is spent.
> As an initial investigation, it would be good to profile the CPU utilisation on one of the CI nodes (take it offline) whilst running these tests. Also, it would be handy to find out how much time is spent in a Thread.sleep call (assuming that is where the time is spent).
> My understanding is that Thread.sleep is used to wait for certain background tasks to complete. It's likely that Byteman could be used to replace the sleeps. However, due to the number of tests this may not be feasible. Alternatively, we may discover that there is a common set of Byteman rules that could be applied to the majority of tests, which may prove "good enough".
> Also, we may be able to run these tests in parallel. This could drive up CPU utilisation, but would probably also interfere with the timings of the tests meaning that the current thread.sleeps are no longer adequate.
> To summarise, this is a general task to investigate why the tests take so long and to also come up with some candidate solutions to bring the total test duration down.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months