Have a feature you want to implement into Statping!? Awesome! Follow this guide
to see how you can test, compile and build Statping for production use. I
recommend you use make with this process, it will save you time and it will
auto-include many customized parameters to get everything working correctly.
Send all PR's to dev branch!
Requirements
Dependencies
Statping has a couple of required dependencies when testing and compiling the
binary. The Makefile
will make these tasks a lot easier. Take a look at the Makefile to see what
commands are running. Run the command below to get setup right away.
make clean compile build
List of requirements for compiling assets, building binary, and testing.
Compiling Assets
This Golang project uses rice to
compile static assets into a single file. The file source/rice-box.go is never
committed to the Github repo, it is automatically created on the build. Statping
also requires sass to be installed on your local OS. To compile all the
static assets run the command below:
make compile
After this is complete, you'll notice the source/rice-box.go file has been
generated. You can now continue to build, and test.
Testing
Statping includes multiple ways to Test the application, you can run the make
command, or the normal go test command. To see the full experience of your
updates, you can even run Cypress tests which are in the .dev/test folder.
Statping will run all tests in the cmd folder on MySQL, Postgres, and SQLite
databases. You can run make databases to automatically create MySQL and
Postgres with Docker.
Golang Testing:
make test
Cypress UI Testing:
make cypress-test
Test Everything:
make test-all
Build
Statping will build on all operating systems except Windows 32-bit. I
personally use xgo to cross-compile on
multiple systems using Docker. Follow the commands below to build on your local
system.
Build for local operating system:
make compile build
Compile for Production
Once you've tested and built locally, you can compile Statping for all available
operating systems using the command below. This command will require you to have
Docker.
make build-all
What Now
Everything tested, compiled and worked out!? Awesome! 💃 You can now commit your
changes, and submit a Pull Request with the features/bugs you added or removed.
Please remember to also add the Changelog Entry to describe what you have
changed by usingchangelog-go.
If your PR is related to an Issue (ie. on a bug fix or when adding a new notifier)
don't forget adding the related GitHub Issue ID like this: [#270](https://github.com/statping/statping/issues/270)
Check out the example below.
Adding one changelog entry should be done in a separate Commit - not only
because this is a good Committing practice, also because it's separated by your
Changes.
When you fix/ add/ ... more than one thing than please describe it a good, short
and precise sentence. Because everyone wants a good and nice-looking CHANGELOG.md
where all changes of a new Version are documented.
Example for fixing a bug in the UI
~] changelog new "Fix zooming out on graph doesn't load additional data ([#270](https://github.com/statping/statping/issues/270))"
[0] New Feature (Added)
[1] Bug Fix (Fixed)
[2] Feature change (Changed)
[3] New deprecation (Deprecated)
[4] Feature removal (Removed)
[5] Security fix (Security)
[6] Other (Other)
>> 1
