Merge branch 'develop' into feature/readd-bounty-#185

Jenkinsfile

@@ -25,7 +25,11 @@ def dockerreponame = "statusim/openbounty-app"
 		}
 
 		stage('Deploy') {
-			build job: 'status-openbounty/openbounty-cluster', parameters: [[$class: 'StringParameterValue', name: 'DEPLOY_ENVIRONMENT', value: "dev"], [$class: 'StringParameterValue', name: 'BRANCH', value: env.BRANCH_NAME]]
+			if ( currentBuild.rawBuild.getCauses()[0].toString().contains('UserIdCause') ){
+				build job: 'status-openbounty/openbounty-cluster', parameters: [[$class: 'StringParameterValue', name: 'DEPLOY_ENVIRONMENT', value: "dev"], [$class: 'StringParameterValue', name: 'BRANCH', value: env.BRANCH_NAME]]
+			} else {
+				echo "No deployment on automatic trigger, go to Jenkins and push build button to deliver it."
+			}
 		}
 
 	} catch (e) {

README.md

@@ -13,6 +13,15 @@ Live testnet (Ropsten) version:
 https://openbounty.status.im:444
 The `develop` branch is automatically deployed here.
 
+## Table of contents
+- [Prerequisites](#prerequisites)
+- [Application config](#application-config)
+- [GitHub integration](#github-integration)
+- [Running](#running)
+- [Testing](#testing)
+- [More info](#more-info)
+
+
 
 ## Prerequisites
 
@@ -47,16 +56,6 @@ brew install https://raw.githubusercontent.com/web3j/homebrew-web3j/881cf369b551
 brew pin web3j
 ```
 
-## Running
-
-Launch following commands each in its own shell:
-
-```
-lein run
-lein figwheel
-lein less auto
-```
-
 ## Application config
 
 Make sure to create `/config-dev.edn` and populate it correctly, which is based on `env/dev/resources/config.edn`. Description of config fields is given below:
@@ -92,20 +91,38 @@ Follow the steps [here](https://developer.github.com/apps/building-github-apps/c
 
 ## Running
 
-Lauch a local geth node with the bot account unlocked:
+### Geth
+Launch a local geth node with the bot account unlocked:
 
 ```
 #!/bin/bash
 geth --fast --testnet --cache=1024 --datadir=$HOME/.ropsten --verbosity 4 --port 50100 --ipcpath ~/.ropsten/geth.ipc --rpc --rpcaddr 127.0.0.1 --rpcport 8545 --rpcapi db,eth,net,web3,personal --rpccorsdomain "https://wallet.ethereum.org" --unlock "0xYOUR_ADDR" --password <(echo "YOUR_PASSPHRASE")
 ```
 
+### CSS auto-compilation
 Launch the following command in a separate shell:
 
 ```
 lein less auto
 ```
 
-Next you want to start a REPL on the backend and the frontend.
+### Solidity compilation
+Invoke `build-contracts` Leiningen task to compile Solidity files into Java classes:
+```
+lein build-contracts
+```
+
+### Clojure app without REPL
+Launch following commands each in its own shell:
+
+```
+lein run
+lein figwheel
+```
+
+### Clojure app with REPL
+
+You'll have to start a REPL on the backend and the frontend.
 
 ```
 lein repl
@@ -135,7 +152,10 @@ To create a standalone uberjar:
 lein uberjar
 ```
 
-This creates `target/uberjar/commiteth-<git-sha>.jar`
+This creates `target/uberjar/commiteth.jar`. You can run it with the following command from within project root:
+```
+java -Dconf=<path_to_config.edn> -jar target/uberjar/commiteth.jar
+```
 
 
 ## Testing
@@ -174,8 +194,8 @@ Landing page is static and different CSS and JS due to time constraints.
 This copies over necessary artifacts to `resources` dir.
 
 
-### Troubleshooting
-See the [Cookbook](doc/cookbook.md).
+## More info
+Detailed information on code structure, troubleshooting, etc. can be found [here](doc/README.md).
 
 ## License
 

doc/core_testing_workflow.md

@@ -0,0 +1,27 @@
+# Testing pull requests in Open Bounty
+
+All new functionality and features both are being delivered by pull requests (hereinafter PRs).
+How to test PR? Steps below could help a bit!
+
+### Prerequisites
+Requirements for PRs to be tested:
+* should be in `To test` column in `Pipeline For Pull Requests` project
+* shouldn't have conflicts with `develop` branch
+* should have a successful build in Jenkins [status-openbounty-app](https://jenkins.status.im/job/status-openbounty/job/status-openbounty-app/view/change-requests/)
+
+
+### Deployment
+In order to deploy feature to [testing env](https://testing.openbounty.status.im/) you should **rebuild** PR you are about to test.  
+
+Only one PR can be deployed on [testing env](https://testing.openbounty.status.im/)
+
+Fresh develop branch with last changes is deployed automatically on [staging env](https://openbounty.status.im:444) 
+
+### Testing
+1)  Move appropriate PR card to IN TESTING on the [Board](https://github.com/status-im/open-bounty/projects/3) and let people know you are on it - assign it to yourself! :)
+2)  Сheck the functionality current PR fixes / delivers (positive/negative tests related to the feature). In curtain cases it's worth to look in 'Files changed' tab in GitHub to check the list of what was changed to get understanding of the test coverage or "weak" places that have to be covered. Ask PR-author in #openbounty channel in slack what was changed if it's not clear from the notes in PR.
+3)  Check reasonable regression using [SOB-general test suite](https://ethstatus.testrail.net/index.php?/suites/view/27&group_by=cases:section_id&group_order=asc)
+4)  No issues? Perfect! Put appropriate label to the PR (`Tested - OK`), merge it to develop and move the PR instance to `Merged to develop`. 
+5)  Found issues? Check for duplicates before adding one. Hint: make sure the issue is really introduced by current PR - check latest `develop` branch on [staging env](https://openbounty.status.im:444) . Issue exists in develop? Check existing issues list and make sure you are not adding duplicates before creating your own bug :)  **All PR-specific issues should be added as comments to tested PR.** 
+Once all issues are logged put label `Tested-issues` to the PR and notify developer that there are several problems that are preventing the PR to merge. Move the PR to `Reviewing, waiting for contributor` on the board if PR is developed by external contributor, and to `Developing` - if it is presented by core contributor.
+

doc/decisions/0001-record-decisions.md

@@ -0,0 +1,40 @@
+# 1. Record Decisions
+
+| Date       | Tags    |
+|------------|---------|
+| 2018-02-16 | process |
+
+## Status
+
+Proposed
+
+## Context
+
+We make a lot of decisions during the life of a project and
+documenting those decisions would help new team members and outside
+contributors follow our thinking. It also opens up an opportunity for
+constructive criticism around those decisions which will result
+in better decision making.
+
+We want to develop a product in the open. Opening up our decision making process for outside contributors is an important part in providing the opportunity to take ownership and impact the project in non-trivial ways.
+
+Recording decisions will also be a useful form of documentation in general as it does not get out of date. All that's documented is that a decision has been made at a certain point in time.
+
+## Decision
+
+We will adopt a format similar to [Architecture Decision
+Records](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) (ADR)
+to propose and document notable decisions. In contrast to ADRs we will try to embrace this tool for more than just architectural concerns. Decisions regarding development practices and product direction are just as important.
+
+What decisions are notable and which are not is left to common-sense and informal consensus among the team.
+
+Decisions may be proposed and discussed informally, should however eventually end up — with all relevant discussion summarized — in the `doc/decisions/` directory of this repository.
+
+Decisions are numbered to have a clear identifier.
+
+## Consequences
+
+- We need to document that we record decisions this way and where people can find those documents.
+- We should probably provide some pointers around tooling to better work with decision records. [`adr-tools`](https://github.com/npryce/adr-tools) comes to mind.
+- Since we deviate from ADRs a bit (we document more than architecture-related decisions) we might need to provide different templates than what comes with tools like `adr-tools` by default.
+  A template like this may also be useful to guide decision authors to provide appropriate context.

doc/decisions/0002-sign-commits-with-gpg.md

@@ -0,0 +1,52 @@
+# 2. Sign Commits With GPG
+
+| Date       | Tags              |
+|------------|-------------------|
+| 2018-02-16 | process, security |
+
+
+## Status
+
+Proposed
+
+## Context
+
+OpenBounty is a system which has value flowing through it.
+Naturally security is a concern that should be taken into consideration.
+
+Currently an attacker might get access to an account of a team member
+and pose as that developer, merging PRs and pushing changes.
+
+Status.im as a company is also encouraging the use of GPG signing and
+has a Pull Request check in place on Github. This check will mark PRs
+as failing if the commits come from an organization member and have not
+been GPG-signed.
+
+## Decision
+
+In order to verify that commits in the repository are actually authored by the specified
+author we adopt [GPG signing of Git commits](https://git-scm.com/book/id/v2/Git-Tools-Signing-Your-Work).
+
+This will allow us to verify authenticity of the author information saved in
+a Git commit and make workflows like deploying on push safer.
+
+It also introduces some complexity because contributors who want to sign
+their commits need to set up the appropriate tooling. Due to that we will
+not require outside contributors to sign their commits for now.
+
+Adopting GPG signing for contributors will also make our PR checks pass
+allowing us to more easily discern actually broken and working PRs.
+
+## Consequences
+
+GPG signing is only making things safer if we have a trusted way of
+exchanging public keys. In the scenario outlined above a user who got access
+to GitHub could simply upload an additional key.
+
+This is currently a work-in-progress within the wider Status organization
+and we'll have to wait to see what comes out of that.
+
+## Appendix
+
+- [GitHub's instructions for setting up GPG signing](https://help.github.com/articles/signing-commits-using-gpg/)
+- More discussion around the usefulness of GPG signing in [issue #285](https://github.com/status-im/open-bounty/issues/285)

doc/decisions/README.md

@@ -0,0 +1,14 @@
+# Decisions
+
+We record decisions. More context on why and how we do that can be found in [DR-0001](doc/decisions/0001-record-decisions.md).
+
+The remainder of this document is intended to document tooling around this process.
+
+### Utilities to Write Decision Records
+
+- `doc/decisions/templates/template.md` - contains a template for a decision record.
+- When recording a decision follow the established file name format
+  `XXXX-some-title.md` where XXXX is the ever increasing count of decisions
+  we've made.
+
+> More to come. Perhaps document how we can use [`adr-tools`](https://github.com/npryce/adr-tools)

doc/decisions/templates/template.md

@@ -0,0 +1,31 @@
+# NUMBER. TITLE
+
+| Date | Tags |
+|---|---|
+| DATE | e.g: architecture, database |
+
+
+## Status
+
+STATUS
+
+Common states: proposed, accepted, rejected, deprecated, superseded
+
+## Context
+
+Describe the context in which the decision has been made.
+Some questions that should give some ideas what to write here:
+
+- What problems have you encountered that this decision impacts?
+- What is the current state of things that are related to this decision?
+
+## Decision
+
+Describe your decision.
+
+- In what ways does it solve the aforementioned problems or improves something?
+- What tradeoffs does this decision make?
+
+## Consequences
+
+Expand on tradeoffs and other side-effects of this decision.

doc/development_workflow.md

@@ -0,0 +1,74 @@
+# Development process in Status Open Bounty
+
+We have a continuously deployed version tracking the `develop` branch live at [test environment](https://openbounty.status.im:444). It uses the [Ropsten](https://ropsten.io/) Ethereum testnet. Any one is welcome to use it and contribute to Open Bounty.
+
+Any help is greatly appreciated!
+Currently we use two projects -  `Pipeline For Issues` and `Pipeline For Pull Requests`, issues and pull requests in our repository are passing through all or several stages described below.
+Whole team is responsible to keep the projects with accurate information.
+
+**If issue or pull request marked with `Blocked` label, it means that it is blocked on some stage, reason of blocking have to be in comment.** 
+
+## Pipeline For Issues
+
+Team is working only on issues that included in this project.
+Issues can be added to this project by any core team member.
+
+#### To define
+This is backlog for all features/issues/enhancements which we want to include to development process. 
+
+All issues here should be marked with:
+
+* **type** - `bug`, `tech-debt`,` enhancement` labels. Issues with `proposal` label should be converted to `bug`, `tech-debt`,` enhancement` before addidng to project.
+* **priority** - `Prio: high`, `Prio: med`, `Prio: low` labels. On the board inside issues with same priority sorting from higher to lower priority is applied.
+
+#### Defining
+The column is intended for issues not completely clear or for features, that should be splitted to smaller issues in order to go ahead.
+After defining all issues that are intended to develop should have size label
+
+* `Size: XS` - 1-2 hours,
+* `Size: S` - 2-4 hours,
+* `Size: M` - 4-8 hours,
+* `Size: L` - 8-20 hours,
+* `Size: XL` - 20-40 hours,
+* `Size: XXL` - 40-60 hours.
+
+#### To design
+It is used for issues that are already defined and require designing process.
+#### Designing
+It shows up that issues are currently in designing process.
+#### To develop
+It stores issues which are ready for development.
+They are explained, clear, designed and **small enough to create one pull request per issue.**
+#### In Bounty
+The store with issues which are open bounties. When we put funds to issue and it shows up in [status open bounty](https://openbounty.status.im), we move issue here.
+#### Developing
+This is for issues that are currently developing, so pull requests assosiated with issues have to be placed in `Pipeline for Pull Request` project. 
+#### Done
+It stores issues with merged to `master` pull requests.
+## Pipeline For Pull Requests
+
+#### Developing
+Contains all open pull requests (hereinafter PRs) that already assosiated with issues.
+#### Reviewing, waiting for contributor
+It keeps all PRs from external contributors which should pass `Reviewing` stage.
+#### Reviewing
+The storage for all  PRs that pass reviewing process.
+Review  process is discussed [here](https://github.com/status-im/open-bounty/issues/221)
+The number of reviewers should be proportional to the complexity of the change and may vary from PR to PR.
+Recommended:
+* PR is trivial (from core contributor) - 1 approval from core contributor
+* PR is normal (or from external contributor) - 2 or more approvals from core contributors
+* PR need to be based on and opened against the `develop` branch.
+* If a PR has undergone review and requires changes from author, move it back to `Contributor` column
+#### To test
+All PRs, that are already developed, reviewed, and haven't conflicts with `develop` branch, so ready to be tested.
+In case if PR has conflict - it is moved to `Reviewing, waiting for contributor` for external contributors or to `Developing` for core contributors.
+#### Testing
+Contains all PRs that are currently should pass through testing process, which is described in `core_testing_workflow.md`.
+After testing two scenarios possible:
+* no issues assosiated with PR - `Tested: OK` label, merge to develop (using `Merge` button) to `Merged to develop`
+* issues found - all of them are created as comments to current PR and PR is moved to `Developing`
+#### Merged to develop
+Keeps PRs that should be merged to `master` and deployed to [prod environment](https://openbounty.status.im/)
+#### Done
+Stores all merged and closed PRs.

env/dev/clj/user.clj

@@ -1,15 +1,34 @@
 (ns user
   (:require [mount.core :as mount]
-            [commiteth.figwheel :refer [start-fw stop-fw cljs]]))
+            [commiteth.figwheel :refer [start-fw stop-fw cljs]]
+            [clojure.tools.namespace.repl :as repl]))
 
-(defn start []
+(repl/set-refresh-dirs "src" "dev" "test")
+
+(defn start
+  "Start all the application components"
+  []
   (require 'commiteth.core)
   (mount/start-without (ns-resolve 'commiteth.core 'repl-server)))
 
-(defn stop []
+(defn stop
+  "Stop all the application components"
+  []
   (require 'commiteth.core)
   (mount/stop-except (ns-resolve 'commiteth.core 'repl-server)))
 
+(defn refresh
+  "Reload the latest namespace definitions"
+  []
+  (repl/refresh))
+
+(defn reset
+  "Restart application after refreshing namespace definitions"
+  []
+  (stop)
+  (repl/refresh :after 'user/start))
+
 (defn restart []
+  "Restart without refreshing namespace definitions"
   (stop)
   (start))