Merge pull request #147 from salabs/develop

Release 1.1.0

.github/workflows/publish-to-docker-hub.yml

@@ -0,0 +1,43 @@
+name: publish-to-docker-hub
+on:
+  pull_request:
+    types: [closed]
+    branches:
+      - master
+jobs:
+  main:
+    runs-on: ubuntu-latest
+    if: github.event.pull_request.merged
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v1
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v1
+
+      - name: Login to DockerHub
+        uses: docker/login-action@v1
+        with:
+          username: ${{ secrets.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+      - name: Build and push frontend
+        uses: docker/build-push-action@v2
+        with:
+          context: frontend
+          file: frontend/Dockerfile-prod-with-template
+          push: true
+          tags: siilisalabs/epimetheus-frontend:latest
+
+      - name: Build and push backend
+        uses: docker/build-push-action@v2
+        with:
+          context: backend_server
+          file: backend_server/Dockerfile
+          push: true
+          tags: siilisalabs/epimetheus-backend:latest
+

CONTRIBUTING.md

@@ -10,11 +10,65 @@ Examples of contributions include:
 
 Patches can be submitted as pull requests, but if you don't file an issue, it may be ignored. Please file an issue to suggest changes.
 
+## Branch naming and commit messages
+Please start a new branch name with ```feature```, ```bug``` or ```hotfix``` depending on the type of the issue, and then add the related issue's number. The rest of the branch’s name should be short and descriptive.<br>
+**Example:**
+>```“feature/21-more-documentation”```
+
+Commit messages should always start with the number of the issue that they're related to. Please avoid commits that are not related to any issue.
+- If you have a small fix that's somehow related to the current issue on hand, feel free to fix it as well.
+- If your fix isn't related to the issue, consider creating a new issue and create a different pull request.
+- If you have a small fix that's **not** related to the issue and decide to fix it anyway, please remember to mention it in the issue's or pull request's description.
+- Small and general fixes like correcting a typo or updating the documentation don't require an issue number.
+
+## Pull requests
+Before making a pull request, please rebase the local branch to the [```develop```](https://github.com/salabs/Epimetheus/tree/develop) branch and squash any unnecessary commits.
+
+Pull request's title should contain the related issue's number, and the pull request should be linked to the related issue.
+
+Pull request requires one approval before it’s possible to merge. The pull request is merged by the reviewer, but in case there are only little improvements to be done after the first review, the reviewer can give an approval beforehand and after the fixes have been done, the pull request’s creator can merge it.
+
+If the individual commits add value to the history and you want to keep all of them, please use the **“Rebase and merge”** option when merging the pull request.
+
+If the individual commits **don't** add value to the history, please use the **"Squash and merge"** option to squash the commits into a single commit when merging the pull request.
+
+Branches should be automatically deleted after they are merged.
+
 ## Coding style
 Epimetheus project uses [EditorConfig](https://editorconfig.org/) to manage the coding style. See the [.editorconfig](/.editorconfig) file
 for settings.
 
 ## Release strategy
-Project uses semantic versioning, and all the pull requests are first created in to develeop branch. Releases are done regurlary when there are new commits in the development branch. The releases are done with a merge commit that has release version numbering in semantic order (Major, Minor, Patch) (Semantic versioning: <https://semver.org/>)
+Project uses semantic versioning, and all the pull requests are first created in to ```develop``` branch. Releases are done regularly when there are new commits in the development branch. The releases are done with a merge commit that has release version numbering in semantic order (Major, Minor, Patch) (Semantic versioning: <https://semver.org/>)
+
+![image](./release_strategy.png)
 
-![image](./release_strategy.png)
+## Step-by-step example of contributing
+1. Checkout to ```develop``` branch:
+```
+git checkout develop
+```
+2. Checkout to a new branch and name it according to the issue's type and number:
+```
+git checkout -b <issuetype/issuenumber-description>
+```
+3. Commit changes with a clear and descriptive note that starts with the issue number:
+```
+git add
+git commit -m "issuenumber - description of changes"
+```
+4. Sync with ```develop``` branch:
+```
+git checkout develop
+git pull
+```
+5. Rebase the ```develop``` branch into the local branch. Use ```--interactive/--i``` flag to reword or squash commits:
+```
+git checkout <issuetype/issuenumber-description>
+git rebase develop
+```
+6. Push the local branch:
+```
+git push
+```
+7. Create a pull request and follow the given guidelines. Make sure the ```base``` is set to ```develop```.

README-docker.md

@@ -30,3 +30,11 @@ Frontend runs on: [http://localhost:3000](http://localhost:3000/)
 [Dockerfile-prod](./frontend/Dockerfile-prod) has two build arguments; `nginx_port` and `backend_url` with default values `8080` and `http://backend-server:5000`.
 The `nginx_port` argument configures the port which the Ngnix service runs inside the Docker and the `backend_url` argument tells the Nginx service
 where to route backend server requests. This arguments can be configured when building the Docker image.
+
+### Running docker-compose with public images
+
+There are also prebuilt images that you can use by running the command.
+
+`$env:ENV_FILE="configfile.env"; docker-compose -f .\docker-compose-from-remote.yml up --build`
+
+Note that currently the public images are built with the default arguements as defined in the chapter before.

README.md

@@ -45,6 +45,7 @@ Once you have both frontend and backend running, you can open your browser to [h
 
 Note that there should be some data saved in the database before user interface will show something. For pushing data into database, consult [TestArchiver documentation](https://github.com/salabs/TestArchiver).
 
+## Installation with docker
 Running project with [Docker](/README-docker.md)
 
 ## Browser Support
@@ -65,7 +66,23 @@ Supported browsers are "all modern browsers". This means IE and some mobile brow
 
 ## Release Notes
 
--   1.0.1 (21.10.2020)
+-   1.1.0 (2021-03-12)
+
+    -   Simple build results API
+    -   Analysis view for a build with keyword analysis table
+    -   Keyword analysis API
+    -   Accessibility improvements
+    -   Style and file name refactoring
+    -   Dockerhub publishing for new releases
+    -   Features:
+        * #141 Style and refactor the keyword analysis table enhancement
+        * #138 Fix various bugs caused by the grid bug
+        * #137 Simple single build results API enhancement
+        * #135 Keyword execution time analysis tool enhancement
+        * #133 Accessibility fix for checkbox bug
+        * #131 Check color usage enhancement
+
+-   1.0.1 (2020-10-21)
 
     -   Fixes a bug which prevented the frontend container from starting when using docker-compose
     -   Changes the default port of Nginx in Dockerfile-prod container from 80 to 8080. Services in Docker containers are now running as non root user.
@@ -74,7 +91,7 @@ Supported browsers are "all modern browsers". This means IE and some mobile brow
     -   Queryparams are now properly shown when switching between Overview and History layouts
     -   Queryparams are properly removed from state if not needed
 
--   1.0.0 (22.9.2020)
+-   1.0.0 (2020-09-22)
     -   Completely updated layout and colour palette
     -   Updated Breadcrumb nav
     -   Overview -page for Series and Builds with graphical visualisation

backend_server/database.py

@@ -92,6 +92,10 @@ def suite_result(self, test_series, build_number, suite):
         sql = sql_queries.suite_result(test_series, build_number, suite)
         return self.session.query(sql), suite_result_data
 
+    def simple_build_result(self, test_series, build_number):
+        sql = sql_queries.simple_build_results_data(test_series, build_number)
+        return self.session.query(sql), simple_build_result_data
+
     def suite_log_messages(self, test_run_id, suite):
         sql = sql_queries.log_messages(test_run_id, suite_id=suite)
         return self.session.query(sql), list_of_dicts
@@ -107,6 +111,9 @@ def keyword_tree(self, fingerprint):
     def subtrees(self, fingerprint):
         return self.session.query(sql_queries.SUBTREES, {'fingerprint': fingerprint}), list_of_dicts
 
+    def keyword_analysis(self, test_series, build_number):
+        return self.session.query(sql_queries.keyword_analysis(test_series, build_number)), list_of_dicts
+
 
 def list_of_dicts(rows):
     results = []
@@ -185,6 +192,21 @@ def suite_result_data(rows):
         current_suite['tests'] = tests
     return current_suite
 
+def simple_build_result_data(rows):
+    suites = []
+    current_suite = None
+    for row in list_of_dicts(rows):
+        suite, test = _separate_suite_and_test_values(row)
+        if not current_suite or suite['id'] != current_suite['id']:
+            suites.append(suite)
+            current_suite = suite
+            current_suite['tests'] = []
+        if test['id']:
+            current_suite['tests'].append(test)
+    if current_suite:
+        suites.append(current_suite)
+    return suites
+
 def _separate_suite_and_test_values(row):
     suite = {key[6:]: row[key] for key in row if key.startswith('suite_')}
     test = {key: row[key] for key in row if not key.startswith('suite_')}