Merge branch 'release/2.1'

CONTRIBUTING.md → .github/CONTRIBUTING.md

@@ -1,27 +1,55 @@
-# Development Ideology
+### Submitting Pull Requests
 
-Truths which we believe to be self-evident (adapted from [TextSecure's](https://github.com/WhisperSystems/TextSecure/blob/master/contributing.md))
+We'd love for you to contribute to our source code and to make this package even better than it is
+today! Here are the guidelines we'd like you to follow:
 
-1. **The answer is not more options.** If you feel compelled to add a preference that's exposed to the user, it's very possible you've made a wrong turn somewhere.
-2. **There are no power users.** The idea that some users "understand" concepts better than others has proven to be, for the post part, false. If anything, "power users" are more dangerous than the test, and we should avoid exposing dangerous functionality to them.
-3. **If it's "like PGP," it's wrong.** PGP is our guide for what not to do.
-4. **It's an asynchronous world.** We wary of anything that is anti-asynchronous: ACKs, protocol confirmations, or anly protocol-level "advisory" message.
-5. **There is no such thing as time**. Protocol ideas that require synchonized clocks are doomed to failure.
+ - [Issues and Bugs](#issue)
+ - [Feature Requests](#feature)
+ - [Coding Rules](#rules)
+ - [Commit Message Guidelines](#commit)
 
-# Code Style Guidelines
+## <a name="issue"></a> Found an Issue?
 
-## Resulting from long experience
+If you find a bug in the source code or a mistake in the documentation, you can help us by
+submitting an issue to our GitHub Repository. Even better you can submit a Pull Request
+with a fix. But first search if the issue is already described!
+
+If not create a new issue:
+
+* Tell about your environment:
+  * node version
+  * nativescript version
+  * used platform and versionÍ
+* Describe your issue
+  * describe your steps leading to the issue
+  * attach error logs or screenshots
+  * if possible provide test case or screenshots
+
+## <a name="feature"></a> Want a Feature?
+
+You can request a new feature by submitting an issue to our [GitHub Repository][github].
+
+Please follow these basic steps to simplify pull request reviews - if you don't you'll probably just be asked to anyway.**
+
+* Please rebase your branch against the current develop, use the **develop** for pull requests
+* Please ensure that the test suite passes **and** that code is lint free before submitting a PR by running:
+ * ```./mvnw test```
+ * Verify plugin is working via docker test ```docker compose up```
+* If you've added new functionality, **please** include tests which validate its behaviour
+* Make reference to possible [issues](https://github.com/jenkinsci/log-parser-plugin/issues) on PR comment
+
+### Resulting from long experience
 
 * To the largest extent possible, all fields shall be private. Use an IDE to generate the getters and setters.
 * If a class has more than one `volatile` member field, it is probable that there are subtle race conditions. Please consider where appropriate encapsulation of the multiple fields into an immutable value object replace the multiple `volatile` member fields with a single `volatile` reference to the value object (or perhaps better yet an `AtomicReference` to allow for `compareAndSet` - if compare-and-set logic is appropriate).
 * If it is `Serializable` it shall have a `serialVersionUID` field. Unless code has shipped to users, the initial value of the `serialVersionUID` field shall be `1L`.
 
-## Indentation
+### Indentation
 
 1. **Use spaces.** Tabs are banned.
 2. **Java blocks are 4 spaces.** JavaScript blocks as for Java. **XML nesting is 2 spaces**
 
-## Field Naming Conventions
+### Field Naming Conventions
 
 1. "hungarian"-style notation is banned (i.e. instance variable names preceded by an 'm', etc)
 2. If the field is `static final` then it shall be named in `ALL_CAPS_WITH_UNDERSCORES`.
@@ -31,20 +59,20 @@ Truths which we believe to be self-evident (adapted from [TextSecure's](https://
 6. It is acceptable to use `e` for the exception in a `try...catch` block.
 7. You shall never use `l` (i.e. lower case `L`) as a variable name.
 
-## Line Length
+### Line Length
 
 To the greatest extent possible, please wrap lines to ensure that they do not exceed 120 characters.
 
-## Maven POM file layout
+### Maven POM file layout
 
 * The `pom.xml` file shall use the sequencing of elements as defined by the `mvn tidy:pom` command (after any indenting fix-up).
 * If you are introducing a property to the `pom.xml` the property must be used in at least two distinct places in the model or a comment justifying the use of a property shall be provided.
 * If the `<plugin>` is in the groupId `org.apache.maven.plugins` you shall omit the `<groupId>`.
 * All `<plugin>` entries shall have an explicit version defined unless inherited from the parent.
 
-## Java code style
+### Java code style
 
-### Modifiers
+#### Modifiers
 
 * For fields, the order is:
     - public / protected / private
@@ -67,23 +95,23 @@ To the greatest extent possible, please wrap lines to ensure that they do not ex
     -  final
     -  strictfp
 
-### Imports
+#### Imports
 
 * For code in `src/main`:
-    - `*` imports are banned. 
+    - `*` imports are banned.
     - `static` imports are strongly discouraged.
     - `static` `*` imports are discouraged unless code readability is significantly enhanced and the import is restricted to a single class.
 * For code in `src/test`:
     - `*` imports of anything other than JUnit classes and Hamcrest matchers are banned.
     - `static` imports of anything other than JUnit classes and Hamcrest matchers are strongly discouraged.
     - `import static org.hamcrest.Matchers.*`, `import static org.junit.Assert.*` are expressly permitted. Any other `static` `*` imports are discouraged unless code readability is significantly enhanced and the import is restricted to a single class.
 
-### Annotation placement
+#### Annotation placement
 
 * Annotations on classes, interfaces, annotations, enums, methods, fields and local variables shall be on the lines immediately preceding the line where modifier(s) (e.g. `public` / `protected` / `private` / `final`, etc) would be appropriate.
 * Annotations on method arguments shall, to the largest extent possible, be on the same line as the method argument (and, if present, before the `final` modifier)
 
-### Javadoc
+#### Javadoc
 
 * Each class shall have a Javadoc comment.
 * Each field shall have a Javadoc comment.
@@ -101,16 +129,16 @@ To the greatest extent possible, please wrap lines to ensure that they do not ex
      * The count of widgets
      */
     private int widgetCount;
-    
+
     /**
      * Returns the count of widgets.
      *
-     * @return the count of widgets. 
+     * @return the count of widgets.
      */
     public int getWidgetCount() {
         return widgetCount;
     }
-    
+
     /**
      * Sets the count of widgets.
      *
@@ -122,31 +150,19 @@ To the greatest extent possible, please wrap lines to ensure that they do not ex
     ```
 * When adding a new class / interface / etc, it shall have a `@since` doc comment. The version shall be `FIXME` to indicate that the person merging the change should replace the `FIXME` with the next release version number. The fields and methods within a class/interface (but not nested classes) will be assumed to have the `@since` annotation of their class/interface unless a different `@since` annotation is present.
 
-### IDE Configuration
-
-* Eclipse, by and large the IDE defaults are acceptable with the following changes:
-    - Tab policy to `Spaces only`
-    - Indent statements within `switch` body
-    - Maximum line width `120`
-    - Line wrapping, ensure all to `wrap where necessary`
-    - Organize imports alphabetically, no grouping
-* NetBeans, by and large the IDE defaults are acceptable with the following changes:
-    - Tabs and Indents
-        + Change Right Margin to `120`
-        + Indent case statements in switch
-    - Wrapping
-        + Change all the `Never` values to `If Long`
-        + Select the checkbox for Wrap After Assignement Operators
-* IntelliJ, by and large the IDE defaults are acceptable with the following changes:
-    - Wrapping and Braces
-        + Change `Do not wrap` to `Wrap if long`
-        + Change `Do not force` to `Always`
-    - Javadoc
-        + Disable generating `<p/>` on empty lines
-    - Imports
-        + Class count to use import with '*': `9999`
-        + Names count to use static import with '*': `99999`
-        + Import Layout
-            * import all other imports
-            * blank line
-            * import static all other imports
+## <a name="rules"></a> Coding Rules
+
+To ensure consistency throughout the source code, keep these rules in mind as you are working:
+
+* All features or bug fixes **must be tested** by one or more [specs][unit-testing].
+* All public API methods **must be documented** with jsdoc.
+
+
+* To the largest extent possible, all fields shall be private. Use an IDE to generate the getters and setters.
+* If a class has more than one `volatile` member field, it is probable that there are subtle race conditions. Please consider where appropriate encapsulation of the multiple fields into an immutable value object replace the multiple `volatile` member fields with a single `volatile` reference to the value object (or perhaps better yet an `AtomicReference` to allow for `compareAndSet` - if compare-and-set logic is appropriate).
+* If it is `Serializable` it shall have a `serialVersionUID` field. Unless code has shipped to users, the initial value of the `serialVersionUID` field shall be `1L`.
+
+
+## <a name="commit"></a> Git Commit Guidelines
+
+We're using [Angular Commit Guidelines](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#-git-commit-guidelines)

.github/FUNDING.yml

@@ -0,0 +1,8 @@
+# These are supported funding model platforms
+
+# github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
+#patreon: continuoussecuritytooling
+#open_collective: moleculer
+#ko_fi: # Replace with a single Ko-fi username
+#tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
+custom: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=H8TR8246RCDJG

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,48 @@
+---
+name: Bug report
+about: Create a report to help us improve
+
+---
+
+## Prerequisites
+
+Please answer the following questions for yourself before submitting an issue.
+
+- [ ] I am running the latest version
+- [ ] I checked the documentation and found no answer
+- [ ] I checked to make sure that this issue has not already been filed
+- [ ] I'm reporting the issue to the correct repository
+
+## Current Behavior
+
+<!-- What is the current behavior? -->
+
+## Expected Behavior
+
+<!-- Please describe the behavior you are expecting -->
+
+## Failure Information
+
+<!-- Please help provide information about the failure if this is a bug. If it is not a bug, please remove the rest of this template. -->
+
+### Steps to Reproduce
+
+Please provide detailed steps for reproducing the issue.
+
+1. step 1
+2. step 2
+3. you get it...
+
+
+### Context
+
+Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.
+
+* Java version:
+* Jenkins version:
+* Operating System:
+
+### Failure Logs
+```
+
+```

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,17 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+<!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] -->
+
+**Describe the solution you'd like**
+<!-- A clear and concise description of what you want to happen. -->
+
+**Describe alternatives you've considered**
+<!-- A clear and concise description of any alternative solutions or features you've considered. -->
+
+**Additional context**
+<!-- Add any other context or screenshots about the feature request here. -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,35 @@
+## :memo: Description
+
+<!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. -->
+
+### :dart: Relevant issues
+<!-- Please add relevant opened issues -->
+
+### :gem: Type of change
+
+<!-- Please delete options that are not relevant. -->
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
+
+### :scroll: Example code
+```js
+
+``` 
+
+## :vertical_traffic_light: How Has This Been Tested?
+
+Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
+
+- [ ] Test A
+- [ ] Test B
+
+## :checkered_flag: Checklist:
+
+- [ ] My code follows the style guidelines of this project
+- [ ] I have performed a self-review of my own code
+- [ ] **I have added tests that prove my fix is effective or that my feature works**
+- [ ] **New and existing unit tests pass locally with my changes**
+- [ ] I have commented my code, particularly in hard-to-understand areas