PBSA Bounty - 1 : Core-Wallet Builds
Description
PBSA is looking to improve the documentation and release consistency of the Peerplays-Core Wallet. We want to know how to compile and build the wallet for the windows/linux/macosx operating systems.
Details
- The wallet essentially has 3 layers (dl, electron, web). As per the README instructions, each of these directories need to be installed in a particular order before the app can be run/compiled/release
- The wallets release artifacts are being built with the gulpfile located in '/electron/gulpfile.js' and '/electron/tasks/release.js'
- This file queries the OS to determine which OS is being used, and builds an executable for that operating system
- When trying to force the "windows" build on a mac, gulpfile throws an error.
- The wallets release artifacts are being built with the gulpfile located in '/electron/gulpfile.js' and '/electron/tasks/release.js'
- The issue as observed by PBSA devs is that the wallet requires PBSA devs to go through the build / release process on MacOSX, Linux (Ubuntu) and Windows (10) separately to generate the release files.
- We would like to be able to build / release future iterations of the wallet without having to log into the separate operating systems.
Suggestions
- Look into the electron-builder package
Reward
$500 USD
PBSA will payout the equivalent USD value in BTC.
The reward value is based on urgency, severity and perceived difficulty.
Once the reward value has been published, it will not change.
Future bounties are subject to change based on market fluctuations and changing requirements.
Grading Process
All solutions are evaluated on a first come first serve basis.
PBSA will choose the first solution that meets ALL of the requirements.
Our evaluators adhere to the following process when evaluating a submitted solution.
- Evaluate Requirements - Enter Process
- Select next chronological requirement - GOTO Step 1b
- Evaluate requirement - GOTO Step 1c
- If Requirement doesn't meet the definition of done, reject the solution and give reasonable feedback to the submitter - Exit Process
- If Requirement meets the definition of done, accept the requirement and ...
- If Requirement is the last requirement in the list and all requirements have met the definition of done - GOTO Step 2a
- If Requirement is not the last requirement, evaluate the next chronological requirement - GOTO Step 1a
- Select next chronological requirement - GOTO Step 1b
- Closure & Acceptance
- Immediately inform the community of that the bounty has been closed and a solution has been accepted by the team - GOTO Step 2b
- Reach out to the individual/group that submitted the solution for notification of acceptance - GOTO Step 3a
- Reward
- Distribute the reward to the appropriate group/individual - Exit Process
Requirements
Requirement | Description | Acceptance Criteria / Definition of Done |
---|---|---|
Modify the README | Modify the README.md to include instructions specific to how to build and distribute the wallet in the respective operating systems |
|
Modify the Gulp/Electron Pipeline | The pipeline may require modification in order to get the build pipe to generate a stable .exe, .dmg and .deb build. |
|
Executables are functional | Each of the executable files can successfully be run on multiple platforms. |
|
How to Submit
Submit To: Github Repo Pull Request
We will use your GitHub account that you used to submit your solution to contact you in the event that your solution is selected as the winner of the bounty.
- Must contain README.md describing how to run your solution (If standalone codebase)
- Must contain instructions on how to run the code (If PR inside existing codebase)
- Must contain your PPY account
Questions
All questions can be forwarded to bounty@pbsa.info
Disclaimers
- PBSA reserves the right to accept or reject solutions for the following reasons (When Applicable)
- Incomplete Solution
- Requirements do not meet the definition of done
- Incomplete or poorly written documentation
- Low Quality Code
- Debug Console Logs
- Not following coding standards
- Inefficient solution
- Cannot Build/Run Solution
- Incomplete submission
- Missing supporting documents
- Late submissions
- Once a solution has been picked as the valid solution, all other submissions will be discarded