This section is intended to help developers and contributors get a working copy of
crcgen
on their end
1. Clone this repository
git clone https://github.com/notsatan/crcgen
cd crcgen
This section will guide you to setup a fully-functional local copy of crcgen
on your end and teach you how to use it! Make sure you have installed
golangci-lint before following this section!
Note: This section relies on the usage of Makefile. If you
can't (or don't) use Makefile, you can follow along by running the internal commands
from crcgen's
Makefile (most of which are
OS-independent)!
To install all dependencies associated with crcgen
, run the
command
make install
For a watered-down explanation, pre-commit hooks are an abstraction over
git-hooks, allowing you to define a series of commands (or checks), that
would be automatically run every time you use the git commit
command.
The pre-commit hooks used by crcgen
are located within the
.pre-commit-config.yml
file. These hooks are configured to run;
- Series of basic checks (JSON, YAML, XML file schema validation)
- Checks for merge conflicts, and possible leaks of private keys
- File formatters - whitespace trimming, end-of-file fixers
- Checks for executable scripts
- JSON formatters
- Code Formatters
- Test-suite
To install pre-commit, simply use the Makefile command
make local-setup
Note: To install (and use) pre-commit
, make sure you have the latest stable
versions of Python and pip installed!
The Makefile command will install pre-commit on your PC, and attach it to git
hooks -- ensuring pre-commit checks are run every time you use the git commit
command!
The previous section guided you to install pre-commit, ensuring pre-commit runs implicitly before every commit.
However, if needed, you can use the run
command to forcibly run pre-commit
on all
staged files (i.e. files in staging area in git).
To manually run pre-commit on all files (including unstaged files), use
pre-commit run --all-files
Code formatters format your code to match pre-decided conventions. To run automated code formatters, use the Makefile command
make format-codebase
Linters are tools that analyze source code for possible errors. This includes typos, code formatting, syntax errors, calls to deprecated functions, potential security vulnerabilities, and more!
To run pre-configured linters, use the command
make lint
Tests in crcgen
are classified as fast and slow - depending
on how quick they are to execute.
To selectively run tests from either test group, use the Makefile command
make fast-test
OR
make slow-test
Alternatively, to run the complete test-suite -- i.e. fast and slow tests at one go, use the command
make test
The test-suite
is simply a wrapper to run linters, stylecheckers and all tests
at once!
To run the test-suite, use the command
make test-suite
In simpler terms, running the test-suite is a combination of running linters
and all tests one after the other!
Tap for a list of Makefile commands
Command | Description | Prerequisites |
---|---|---|
help |
Generate help dialog listing all Makefile commands with description | NA |
local-setup |
Setup development environment locally | python, pip |
install |
Fetch project dependencies | NA |
codestyle |
Run code-formatters | golangci-lint |
lint |
Check codestyle and run linters | golangci-lint |
test |
Run all tests | NA |
fast-tests |
Selectively run fast tests | NA |
slow-tests |
Selectively run slow tests | NA |
test-suite |
Check codestyle, run linters and tests tests | golangci-lint |
run |
Run crcgen | NA |
docker-gen |
Create production docker image for crcgen | docker |
docker-debug |
Create debug-friendly docker image for crcgen | docker |
clean-docker |
Remove docker image generated by docker-gen |
docker |
Optionally, to see a list of all Makefile commands, and a short description of what they do, you can simply run
make
Which is equivalent to;
make help
Both of which will list out all Makefile commands available, and a short description of what they do!
To generate binaries for multiple OS/architectures, simply run
bash build-script.sh
The command will generate binaries for Linux, Windows and Mac targetting multiple
architectures at once! The binaries, once generated will be stored in the bin
directory inside the project directory.
The binaries generated will be named in the format
crcgen_<version>_<target-os>_<architecture>.<extension>
The <extension>
is optional. By default, version
is an empty string. A custom
version can be passed as an argument while running the script. As an example;
bash build-script.sh v1.2.1
An example of the files generated by the previous command will be;
crcgen_v1.2.1_windows_x86_64.exe
Follow Codecov Docs to activate Codecov for your project repository.
Once you've activated Codecov for your project, you should be able to see the
Repository Upload Token
. Copy this token, and add it as a secret to your Github
repository. Checkout Creating secrets for a Repository for info
on how to add secrets on Github.
For the secret, the name of the secret should be "CODECOV_TOKEN
" (no spaces,
copy-paste the string as it is). The value of the secret would be the
Repository Upload Token
obtained from Codecov.
Save the secret, you should be able to a secret named CODECOV_TOKEN
in the
Settings > Secrets section of your project repository. If this field is visible,
you are done with setting up Codecov, and should be able to see code coverage reports
after the next run of CI pipeline!
To run crcgen
in a docker container, read the instructions in
docker section.
To run crcgen, use the command
make run
Additionally, you can pass any additional command-line arguments (if needed) as the
argument "q
". For example;
make run q="--help"
OR
make run q="--version"
You can check out a list of previous releases on the Github Releases page.
What is Semantic Versioning?
Semantic versioning is a versioning scheme aimed at making software management easier. Following semantic versioning, version identifiers are divided into three parts;
<major>.<minor>.<patch>
MAJOR version when you make incompatible API changes [breaking changes]
MINOR version when you add functionality in a backwards compatible manner [more features]
PATCH version when you make backwards compatible bug fixes [bug fixes and stuff]
For a more detailed description, head over to semver.org
Release Drafter automatically updates the release version as pull requests are merged.
Labels allowed;
major
: Affects the<major>
version number for semantic versioningminor
,patch
: Affects the<patch>
version number for semantic versioning
Whenever a pull request with one of these labels is merged to the master
branch,
the corresponding version number will be bumped by one digit!
Pull requests once merged, will be classified into categories by release-drafter based on pull request labels
This is managed by the release-drafter.yml
config file.
Label | Title in Releases |
---|---|
security |
π Security |
enhancement , feature , update |
π Updates |
bug , bugfix , fix , hotfix |
π Bug Fixes |
documentation |
π Documentation |
wip , in-progress , incomplete , partial |
π§ Work in Progress |
dependencies , dependency |
π¦ Dependencies |
refactoring , refactor , tests , testing |
π§ͺ Tests and Refactor |
build , ci , pipeline |
π€ CI/CD and Pipelines |
The labels bug
, enhancement
, and documentation
are automatically created by Github
for repositories. Dependabot will implicitly create the
dependencies
label with the first pull request raised by it.
The remaining labels can be created as needed!