GitHub workflows

.github/workflows/maven.yml

@@ -0,0 +1,24 @@
+name: Java CI with Maven
+
+on:
+  push:
+    branches:
+      - master
+  pull_request:
+    branches:
+      - master
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        java: [ 8, 11, 12, 13 ]
+    name: Java ${{ matrix.java }} compile
+    steps:
+      - uses: actions/checkout@master
+      - name: Setup java
+        uses: actions/setup-java@v1
+        with:
+          java-version: ${{ matrix.java }}
+      - run: mvn test

README.md

@@ -30,7 +30,7 @@ The plugin is designed to automate the **[CoDE:U Git Flow](https://www.praqma.co
 ## Plugin repositories
 
 * [Jenkins CI on Github](https://github.com/jenkinsci/pretested-integration-plugin) (used as final archive for released version)
-* [Praqma's on github](https://github.com/Praqma/pretested-integration-plugin) (used to release from and accept pull requests)
+* [Praqma's on Github](https://github.com/Praqma/pretested-integration-plugin) (used to release from and accept pull requests)
 * [Migration guide 2.X -> 3.X](https://wiki.jenkins.io/display/JENKINS/Pretested+Integration+Plugin) (Migration guide from wiki)
 
 
@@ -61,7 +61,7 @@ The recommended workflow are described in our user documentation on the [Pretest
 Concepts:
 
 * The **ready branch** the developer branch with changes, that should be integrated. It is called ready, because of our recommended naming conventions in the [CoDe:U Git Flow](https://www.praqma.com/stories/git-phlow/).
-* **Ready** branches are specified by configuring the SCM plugin (not the prestested integration plugin) to pic up changes on those specific branches. For the Git plugin, it is the `Branch Specifier`.
+* **Ready** branches are specified by configuring the SCM plugin (not the pretested integration plugin) to pick up changes on those specific branches. For the Git plugin, it is the `Branch Specifier`.
 * The **integration branch** is the target branch for integration. This is where changes from the ready-branches comes in.
 
 Merge strategies:
@@ -77,7 +77,7 @@ The plugin footprint during the build executions have the following phases:
 * **Integrate**: Integrates SCM changes _locally_ by manipulating the workspace. Executed after changes have been pulled by the SCM plugin, and before any build steps are run.
 * **Publish changes**: As a post-build step, a decision is made based on build result, after all build steps are run, whether to publish the integration.
 
-Before the build phase, a commit is checked out of the _ready_ branch and merged into the _integration branch_ in order to test compatibility. If the build is successfull the integrated changed are published.
+Before the build phase, a commit is checked out of the _ready_ branch and merged into the _integration branch_ in order to test compatibility. If the build is successful the integrated changed are published.
 
 
 ## Build results
@@ -105,7 +105,7 @@ The accumulated commit message can not be generated automatically by git, as the
 This means that locale settings and language in the environment affect the string formatting regarding dates.
 It is an early decision that the accumulated commit message should look the squash commit message.
 
-To make the accumulated commit message look almost identical to the squash message, we use english formatting of the date strings as this seems to be the default behavior for git squash commit message, if autogenerated. Independent from environments.
+To make the accumulated commit message look almost identical to the squash message, we use English formatting of the date strings as this seems to be the default behavior for git squash commit message, if autogenerated. Independent from environments.
 
 See the `GetAllCommitsFromBranchCallback` for actual implementation.
 
@@ -121,17 +121,17 @@ Relates to [JENKINS-29369](https://issues.jenkins-ci.org/browse/JENKINS-29369).
 
 # Only one integration repository is supported
 
-* **Integration only support one repository**: Doing pretested integration on several repositories as the same time would not make sense conceptually. There should also be a 1:1 relation between a Jenkins job and a repository as a best practice. Further it would not be possible to make pretested integration as an atomic non interuptable operation on several repositories. For example if they both integrate successfully, but publishing result fails on the second one. What should then happen with the first one?
+* **Integration only support one repository**: Doing pretested integration on several repositories as the same time would not make sense conceptually. There should also be a 1:1 relation between a Jenkins job and a repository as a best practice. Further it would not be possible to make pretested integration as an atomic non uninterruptible operation on several repositories. For example if they both integrate successfully, but publishing result fails on the second one. What should then happen with the first one?
 
 # Integration tests
 
 Things you want to know...
 
-* if running the integration tests on Windows, 'git.exe' must be in path.
+* if running the integration tests on Windows, `git.exe` must be in path.
 
 ## Static git repositories
 
-We have been using JGit to create test repositories programatically for the functional tests, which means every test created their own repository and for each test run. This approach works fine, but verifying commits in details can be hard as SHAs, timestamps etc. changes pr. test run. Therefore we have taken an _static git repository_ approach, where we create the reposiories (by script or hand) once, and persist them in the repository as a test resource.
+We have been using JGit to create test repositories programmatically for the functional tests, which means every test created their own repository and for each test run. This approach works fine, but verifying commits in details can be hard as SHAs, timestamps etc. changes pr. test run. Therefore we have taken an _static git repository_ approach, where we create the repositories (by script or hand) once, and persist them in the repository as a test resource.
 
 In `src/test/resources/` there is a static git repository collection that can be re-used in tests, or you can create new ones. For details see the file [src/test/resources/howtoTestUsingStaticGitRepos.md](file://src/test/resources/howtoTestUsingStaticGitRepos.md)
 
@@ -141,8 +141,8 @@ In `src/test/resources/` there is a static git repository collection that can be
 
 Our strategy for logging in the plugin is to log:
 
-* **Exceptions**: The automated added logging lines logs for almost all exceptions entering and existing exception handling. That is okay, but we need more information than that - human well described situation report pr. exception. Why did we end there? What do we suspect is wrong? Log those informations, as well as stacktrace message and so fort. Also log if we re-throw the exception. Exception must be **`Level.SEVERE`** or worse.
-* **State transitions or decisions**: Log situations where we change state or make decisions. Examples can be that we can't find the branch, it does not fulfil requirements, there is no new commit etc.  Typically this is placed where we might print something to console for the user, we want that in the log as well. Use log level **`Level.FINE`** or lower.
+* **Exceptions**: The automated added logging lines logs for almost all exceptions entering and existing exception handling. That is okay, but we need more information than that - human well described situation report pr. exception. Why did we end there? What do we suspect is wrong? Log this information, as well as stack trace message and so fort. Also log if we re-throw the exception. Exception must be **`Level.SEVERE`** or worse.
+* **State transitions or decisions**: Log situations where we change state or make decisions. Examples can be that we can't find the branch, it does not fulfill requirements, there is no new commit etc.  Typically this is placed where we might print something to console for the user, we want that in the log as well. Use log level **`Level.FINE`** or lower.
 * **Every user message or output to Jenkins console**: User messages and console output should be logged as well - it will be way easier to follow those large logs, if the same messages we see in Jenkins job console is in the log as well.
 * Log level **Level.WARNING** is typically used for recovered errors.
 * Log **"Doing step..."** and *"Done step ..."* so the most important steps, that can fail write to log or console **before** and **after** the step.
@@ -173,14 +173,14 @@ This is used to release from, and accepting pull request. **Do not make pull req
 * We don't accept changes, that doesn't reference a Jira issue.
 * Every code change must be tested, so there should be either new tests contributed or tests that are changed to new workflows.
 * We currently favor functional testing, going through user scenarios in favor of unit tests. Best of course to contribute to both.
-* Unless it is a simple bugfix, or feature implementation, please consult the  [Pretested Integration Plugin **roadmap** Trello board](https://trello.com/b/tOQL6crl/pretested-integration-plugin) to discuss implementation ideas.
+* Unless it is a simple bug fix, or feature implementation, please consult the  [Pretested Integration Plugin **roadmap** Trello board](https://trello.com/b/tOQL6crl/pretested-integration-plugin) to discuss implementation ideas.
 
 
 ### Creating an SCM interface
 To define a new SCM interface, create a public class which extends "org.jenkinsci.plugins.pretestedintegration.AbstractSCMInterface" and overrides relevant methods. Currently we have no guide or howto on this, but the Git implementation should serve as inspiration.
 
 
-## Acknowledgement
+## Acknowledgment
 
 Code contributions were initially made by Computer Science students at University of Copenhagen [DIKU](https://www.diku.dk) as part of a study project.
 
@@ -210,7 +210,7 @@ I also installed the Stapler plugin, but [their guide](https://wiki.jenkins.io/d
 
 Building with a container so you don't need neither Java or Maven on your computer, and you're sure that the environment is the one we use as well on our build systems.
 
-Find a suitable tagged image on https://hub.docker.com/_/maven/ chosing maven + java combo. Then you could run this command and it will do Maven stuff inside the container:
+Find a suitable tagged image on https://hub.docker.com/_/maven/ choosing maven + java combo. Then you could run this command and it will do Maven stuff inside the container:
 
     docker run -it --rm --name pretested-integration-plugin-maven-build-env -v "$PWD":/usr/src/mymaven -w /usr/src/mymaven maven:3.5-jdk-8 mvn clean install
 
@@ -224,4 +224,4 @@ _Re-use that volume mounting it into the Maven container_ (if you read the Docke
 
     docker run -it --rm --name dev-env-4-pretested-integration-plugin-container -v dev-env-4-pretested-integration-plugin-volume:/root/.m2 -v "$PWD":/usr/src/mymaven -w /usr/src/mymaven maven:3.5-jdk-8 mvn clean
 
-(You should chose short names for container and volume, I just long names to describe the commands better).
+(You should choose short names for container and volume, I just long names to describe the commands better).

pom.xml

@@ -93,6 +93,34 @@
                     <compatibleSinceVersion>3.0.0</compatibleSinceVersion>
                 </configuration>
             </plugin>
+            <plugin>
+                <groupId>org.jacoco</groupId>
+                <artifactId>jacoco-maven-plugin</artifactId>
+                <version>0.8.5</version>
+                <executions>
+                    <execution>
+                        <goals>
+                            <goal>prepare-agent</goal>
+                        </goals>
+                    </execution>
+                    <execution>
+                        <id>jacoco-check</id>
+                        <goals>
+                            <goal>check</goal>
+                        </goals>
+                    </execution>
+                    <execution>
+                        <id>jacoco-report</id>
+                        <phase>test</phase>
+                        <goals>
+                            <goal>report</goal>
+                        </goals>
+                        <configuration>
+                            <outputDirectory>target/jacoco-report</outputDirectory>
+                        </configuration>
+                    </execution>
+                </executions>
+            </plugin>
             <!--
             Allows integration tests to clean test environment before build fails
             use 'mvn verify' to run integration tests to allow 'post-integration-test' phase