Migrating to GH issues

CONTRIBUTING.md

@@ -5,7 +5,7 @@ Want to contribute? Great!
 We try to make it easy, and all contributions, even the smaller ones, are more than welcome.
 This includes bug reports, fixes, documentation, examples...
 
-If you are looking for an issue to work on and haven't had much previous experience with Narayana then you could choose one that has the label [good-first-issue or hacktoberfest](https://issues.redhat.com/browse/JBTM-2493?filter=12421681) or one whose "Estimated Difficulty" field is `Low`. For Hacktoberfest we have created a zulip stream called [hacktoberfest](https://narayana.zulipchat.com/#narrow/stream/406889-hacktoberfest/topic/stream.20events/near/393204842) for discussions. If you want to take an issue then ping a team member (or add a message to the zulip stream) and we will update the assignee field.
+If you are looking for an issue to work on and haven't had much previous experience with Narayana LRA then you could choose one that has the label [good-first-issue](https://github.com/jbosstm/lra/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22). For Hacktoberfest we have created a zulip stream called [hacktoberfest](https://narayana.zulipchat.com/#narrow/stream/406889-hacktoberfest/topic/stream.20events/near/393204842) for discussions. If you want to take an issue then ping a team member (or add a message to the zulip stream) and we will update the assignee field.
 
 On the other hand, if you are set to tackle a big, complicated issue or an issue that will have a high impact on the code base, it is highly recommended to follow the [Request for enhancement (RFE) [workflow](https://github.com/jbosstm/narayana-proposals/blob/main/README.md). Choosing to employ this workflow before starting the development of the selected RFE will help the Narayana core team and yourself to clarify the requirements, the constraints, and the overall design to tackle the issue in advance. In other words, employing the RFE workflow will make sure that the Narayana core team and yourself are on the same page before starting coding.
 
@@ -45,18 +45,7 @@ Although copyright notices on contributions are not strictly necessary we do ask
 ## Reporting an issue
 
 If you believe you found a bug (and all software has bugs) we'll need to know how to reproduce it, what you are seeing and what you would expect to see.
-To report the issue use the [JBTM issue tracker](https://issues.redhat.com/projects/JBTM). Fill in as many fields as are relevant including the following:
-
-- *Affects Version/s*: The version where you found the issue.
-- *Fix Version/s*: Leave this field blank, the engineer who fixes the issue will set the correct version when the PR is merged.
-- *Component/s*: The components relevant to the problem. Leave the field blank if you're not sure which components are affected.
-
-Don't forget to indicate which version of Narayana, Java and Maven you are using.
-
-Additionally, for more involved items of work, if you are able to estimate the work required to fix the issue or RFE please provide, as best you can, details using the following fields:
-
-- *Original and Remaining Estimate* for estimating resources
-- *Estimated Difficulty* for estimating complexity
+To report the issue use the [GitHub issue tracker](https://github.com/jbosstm/lra/issues). 
 
 ## Making open source more inclusive
 
@@ -104,12 +93,9 @@ To contribute, use GitHub Pull Requests (PRs), from your **own** fork.
 When you create a PR, the description field of the PR will include brief instructions on what you need to include.
 But the following guidelines provide a more detailed set of requirements that we have found useful:
 
-1. The Pull Request title is properly formatted: `JBTM-XYZ Subject`
-2. The Pull Request *should* contain a link to the JIRA issue(s) at the start of the PR description (only minor changes to script/text files are exempt from this rule). If the engineer wishes to address multiple issues and they are closely related then they can be addressed in a single PR. The JIRA must contain sufficient information to enable the reader to understand what the issue is, so at a minimum the description field of the JIRA must be present and legible/clear.
-3. If the Pull Request depends on other pull requests, please put the full URL of the pull request(s) that you depend on. Ideally with a prefix "Depends on ".
-4. Engineers are not allowed to submit PRs which only contain formatting changes. The guidance on formatting code are covered in the [Coding Guidelines](#coding-guidelines) section below.
-5. New PRs are tested against multiple Jenkins CI axes. If you know that a change only affects particular axes then you can disable the ones that aren't required, ask a team member for clarification if you're not sure (or look at how the `PROFILE` variable is used in the CI script `scripts/hudson/narayana.sh`. When you first create a PR, the PR description field contains basic instructions about how to disable a CI test axis.
-6. The engineer raising the PR should have tested their changes prior to submitting the request to merge changes. However, there are some circumstances where this may not be possible in which case you must add the label "Hold" and update the PR description indicating why it isn't ready for review just yet. The policy to add the label "Hold" is a signal to reviewers that the changes are not yet ready to be reviewed.
+1. The Pull Request *should* contain a link to the GitHub issue(s) at the start of the PR description (only minor changes to script/text files are exempt from this rule). If the engineer wishes to address multiple issues and they are closely related then they can be addressed in a single PR. The GitHub issue must contain sufficient information to enable the reader to understand what the issue is, so at a minimum the description field of the GitHub issue must be present and legible/clear.
+2. If the Pull Request depends on other pull requests, please put the full URL of the pull request(s) that you depend on. Ideally with a prefix "Depends on ".
+3. The engineer raising the PR should have tested their changes prior to submitting the request to merge changes. However, there are some circumstances where this may not be possible in which case you must add the label "Hold" and update the PR description indicating why it isn't ready for review just yet. The policy to add the label "Hold" is a signal to reviewers that the changes are not yet ready to be reviewed.
 
 Also, make sure you have set up your Git authorship correctly:
 
@@ -128,7 +114,7 @@ A possible exception is that if a change only effects build scripts or non-sourc
 Before asking for a review it's best to wait for [Continuous Integration tests](#continuous-integration) to finish successfully (unless early feedback is being sought).
 
 Once a review has started both parties should attempt to respond to feedback in a timely manner.
-Do not approve the PR until you have either seen a successful CI test of the PR, or you can reasonably explain why a failure is unrelated to the code changes made in the PR (and documented in a PR comment).
+Do not approve the PR until you have either seen a successful GitHub action test of the PR, or you can reasonably explain why a failure is unrelated to the code changes made in the PR (and documented in a PR comment).
 
 #### What can I expect in a code review?
 
@@ -139,8 +125,6 @@ The review procedure is that the reviewer:
 These criteria may be:
 * Not specifically addressing the issue being fixed
 * Clean up changes not being in a separate git commit
-* Commit message not prefixed with a JIRA number
-* Too many separate commits in the same pull request related to the same JIRA and the same part of the change
 
 The person that raised the PR then responds by either:
 * Agreeing - in which case they add the change to their local repo and push to their own github fork of it - this will update the PR
@@ -152,29 +136,22 @@ Once all disagreements have been resolved and any changes after review have been
 
 ### Continuous Integration
 
-To ensure Narayana is stable for everyone, all changes should go through Narayana continuous integration: when you raise a pull request one of the members of the team will schedule a CI run to test your PR.
-Note that when a CI test axis passes there is *no need* to disable further testing of the axis (the danger of doing this is that if further commits are added to the PR then the axis will not be retested).
+To ensure Narayana is stable for everyone, all changes should go through Narayana LRA continuous integration: when you raise a pull request a GitHub action will test your PR.
 
 ### Tests and documentation are not optional
 
 Don't forget to include tests in your pull requests.
 Also don't forget the documentation (reference documentation for features, javadoc...).
 
-## Update the issue with the correct release information:
+## Update the issue when the PR is closed:
+
+If the change would result in behaviour in Narayana LRA that is incompatible with the current release stream for Narayana LRA, then please specify it in the issue description.
 
-If the change would result in behaviour in Narayana that is incompatible with the current release stream for Narayana, then the relevant JIRA issue `Fix Version/s` must be set to the `<version+1>.next`. For example if the root pom.xml is currently `<version>7.0.3.Final-SNAPSHOT</version>` then the JIRA issue should have a `Fix Version/s` of `8.next` added. When resolving the issue in JIRA we encourage the assignee to consider adding a release note describing the impact of the change.
+When the GitHub Pull Request has passed all relevant GitHub action checks and has been approved by a reviewer the code can be merged. If you don't have permission to do this then ping one of the team who will then merge it. Once merged the issue must be updated in the issue tracker (if you don't have permission then a team member will do this):
 
-When the github Pull Request has passed all relevant CI checks and has been Approved by a reviewer the code can be merged. If you don't have permission to do this then ping one of the team who will then merge it. Once merged the issue must be updated in the issue tracker (if you don't have permission then a team member will do this):
+1. Press the `Close issue` (usually it is `Close as completed`))
 
-1. Press the `Pull Request Closed` button (the status will automatically be set to `Done`)
-2. If the `Fix Version/s` is not set to `<version+1>.next`, set the `Fix Version/s` field to `<version>.next`
-   Note that this step is vital since the release process only includes issues in the `Done` state and with the correct `<version>.next` field, otherwise your fix will not be included in the next release.
-   Note that if you merge to a branch other than master please ensure that it is a maintenance release (or, in some cases, a topic branch).
-   The release coordinator will update this `Fix Version` field to correspond with the actual version being released.
-   The release coordinator will also move the status of the issue to `Closed` once it's included in a release.
-4. Sanity check that the other fields have been filled in correctly (although these are normally set when the issue is created):
-5. Please provide meaningful release notes so that potential users can see, at a glance, what new things can be expected from the release that contains the fix.
 
 ## Release
 
-The Narayana project applies the [Semantic Versioning Specification](https://semver.org/) (SemVer) 2.0.0 to mark its releases.
+The Narayana LRA project applies the [Semantic Versioning Specification](https://semver.org/) (SemVer) 2.0.0 to mark its releases.

PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,4 @@
 Thanks for submitting your Pull Request!
 
 Please refer to our [guidelines for making contributions](https://github.com/jbosstm/narayana/blob/main/CONTRIBUTING.md) when creating your pull request. In particular, it helps the reviewer if you ensure that the:
-- [ ] Pull Request title is properly formatted: JBTM-XYZ Subject
-- [ ] Pull Request contains a link to the JIRA issue(s) and that they contain sufficient information for the reviewer to be able to gauge whether or not the proposed changes correctly address the issue
-
+- [ ] Pull Request contains a link to the GitHub issue(s) and that they contain sufficient information for the reviewer to be able to gauge whether or not the proposed changes correctly address the issue

narayana-release-process.sh

@@ -15,7 +15,7 @@ else
   ORG=$3
 fi
 
-echo "You will need: VPN, credentials for jbosstm host, jira admin, github permissions on all $ORG repo and nexus permissions." 
+echo "You will need: VPN, credentials for jbosstm host, github permissions on all $ORG repo and nexus permissions." 
 echo "Please check the configuration in ~/.m2/settings.xml with repository 'jboss-releases-repository' and correct username/password." 
 read -p "Have you done these steps? y/n " STEPSOK
 if [[ $STEPSOK == n* ]]; then

scripts/hudson/narayana.sh

@@ -188,34 +188,6 @@ function comment_on_pull
     fi
 }
 
-function check_if_pull_closed
-{
-    if [ "$PULL_NUMBER" != "" ]
-    then
-      if [[ $PULL_DESCRIPTION =~ "\"state\": \"closed\"" ]]
-      then
-          echo "pull closed"
-          exit 0
-      else
-          echo "pull open"
-      fi
-    fi
-}
-
-function check_if_pull_noci_label
-{
-    if [ "$PULL_NUMBER" != "" ]
-    then
-        if [[ $PULL_DESCRIPTION =~ "\"name\": \"NoCI\"" ]]
-        then
-            echo "pull request $PULL_NUMBER is defined with NoCI label, exiting this CI execution"
-            exit 0
-        else
-            echo "NoCI label is not present at the pull request $PULL_NUMBER"
-        fi
-    fi
-}
-
 function build_narayana {
   echo "Checking if need SPI PR"
   if [ -n "$SPI_BRANCH" ]; then
@@ -330,7 +302,6 @@ function tests_as {
 function init_jboss_home {
   [ -d $JBOSS_HOME ] || fatal "missing AS - $JBOSS_HOME is not a directory"
   echo "JBOSS_HOME=$JBOSS_HOME"
-  cp ${JBOSS_HOME}/docs/examples/configs/standalone-xts.xml ${JBOSS_HOME}/standalone/configuration
   cp ${JBOSS_HOME}/docs/examples/configs/standalone-rts.xml ${JBOSS_HOME}/standalone/configuration
   # configuring bigger connection timeout for jboss cli (WFLY-13385)
   CONF="${JBOSS_HOME}/bin/jboss-cli.xml"
@@ -367,7 +338,7 @@ function lra_tests {
 
 
 function enable_as_trace {
-    CONF=${1:-"${JBOSS_HOME}/standalone/configuration/standalone-xts.xml"}
+    CONF=${1:-"${JBOSS_HOME}/standalone/configuration/standalone.xml"}
     echo "Enable trace logs for file '$CONF'"
 
     sed -e '/<logger category="com.arjuna">$/N;s/<logger category="com.arjuna">\n *<level name="WARN"\/>/<logger category="com.arjuna"><level name="TRACE"\/><\/logger><logger category="org.jboss.narayana"><level name="TRACE"\/><\/logger><logger category="org.jboss.jbossts"><level name="TRACE"\/><\/logger><logger category="org.jboss.jbossts.txbridge"><level name="TRACE"\/>/' $CONF > "$CONF.tmp" && mv "$CONF.tmp" "$CONF"
@@ -413,20 +384,10 @@ ulimit -c unlimited
 ulimit -a
 
 initGithubVariables
-check_if_pull_closed
-check_if_pull_noci_label
 
 init_test_options
 
-# if QA_BUILD_ARGS is unset then get the db drivers form the file system otherwise get them from the
-# default location (see build.xml). Note ${var+x} substitutes null for the parameter if var is undefined
-[ -z "${QA_BUILD_ARGS+x}" ] && QA_BUILD_ARGS="-Ddriver.url=file:///home/jenkins/dbdrivers"
-
-# Note: set QA_TARGET if you want to override the QA test ant target
-
 # for IPv6 testing use export ARQ_PROF=arqIPv6
-# if you don't want to run all the XTS tests set WSTX_MODULES to the ones you want, eg:
-# export WSTX_MODULES="WSAS,WSCF,WSTX,WS-C,WS-T,xtstest,crash-recovery-tests"
 
 [ -z "${WORKSPACE}" ] && fatal "UNSET WORKSPACE"
 
@@ -447,11 +408,6 @@ kill_qa_suite_processes $MainClassPatterns
 
 export MEM_SIZE=1024m
 [ -z ${MAVEN_OPTS+x} ] && export MAVEN_OPTS="-Xms$MEM_SIZE -Xmx$MEM_SIZE"
-export ANT_OPTS="-Xms$MEM_SIZE -Xmx$MEM_SIZE"
-export EXTRA_QA_SYSTEM_PROPERTIES="-Xms$MEM_SIZE -Xmx$MEM_SIZE -XX:ParallelGCThreads=2"
-
-# if we are building with IPv6 tell ant about it
-export ANT_OPTS="$ANT_OPTS $IPV6_OPTS"
 
 # run the job