Go pkg

Go pkg is a tool box to develop with the Golang language.

To maintain a clear history to each packages, this main branch describe the global documentation and the continue integration process.

Go pkg

Packages

example

example package provide an example usage to package life in this library.

errorx

errorx package provide an error management which implement the standar error interface.

httput

httput package provide a tool suite to make an unitaries tests arround http.

server

server package provide a common server http.

gosource

gosource package allows write a go source file dynamically.

Requirements

GNU Make >= 4.1
Compilation tested only on debian and on ubuntu Xenial

Build usage

The Makefile build one makefile to each packages.

process build:

print skin gopkg
install dependancies
linter with golint
test and generate coverage
build packages

make

Rules list

To the make's rules work on the packages, the package need initialized with go module and have a go.mod file.

Make's rules are executed to each go packages and invoke the same rule to their Makefile (the generated makefile behavior are describe by the '*' character).

# install: create Makefile to each go package funded and invoke their rule 'install'
# * download the dependencies describes by the go.mod file
make install

# lint: invoke the 'lint' rule to each generated makefile
# * run golint tool
make lint

# test: invoke the 'test' rule to each generated makefile
# * run tests and generate the rate coverage
make test

# build: invoke the 'build' rule to each generated makefile
# * run the build
make build

# clean: invoke the 'clean' rule to each generated makefile
# * remove the coverages files and binaries files
make clean

# fclean: invoke the 'clean' rule and remove all generated makefile
make fclean

# skin: draw the gopkg's skin
make skin

Repository usage

The main branch describe only continue integration and documentation.

To see the specific documentation to one package, click on the github source badge associated in the Packages section

Versionning

Each packages are versioned with semver rules 2.0.0.

    - MAJOR version when you make incompatible API changes
    - MINOR version when you add functionality in a backwards-compatible manner
    - PATCH version when you make backwards-compatible bug fixes.

CI rules

The ci is executed by travis ci.

All packages start from main branch to inherit of ci functionnalities.

Next, equivalent of master to the new package, should be branchname-release

*-release branchs are protected to be up to date. So force push will not be possible.

Triggers list and behaviors

If branch name match with the next patterns, each commits will be executed by travis ci.

.-dev-.:
- linter
- test
- build
.*-release$
- linter
- test
- build
- release creation

New package

Example process to create a new package 'example'

git clone git@github.com:ymohl-cl/gopkg.git && cd gopkg
git checkout main
git checkout -b example-release
# make your dev ... and add your first version in the package's README file
vim example/README.md
# clean history (important: don't modify the commits which comes from the main branch)
git rebase -i HEAD~?
git push origin example-release

Update package

Example process to update an existing package 'example'

git clone git@github.com:ymohl-cl/gopkg.git && cd gopkg
git checkout example-release
git checkout -b example-dev-myfeaturename
# make your dev ... and update your version in the package's README file
vim example/README.md
# clean history (important: don't modify the commits which comes from the main branch)
git rebase -i example-release
# import ci update if exist
git merge main
git push origin example-dev-myfeaturename
# when the pull request will be accepted, the new release will be automatically created

Update versionning package

You need add the release number in the README.md file for the ci detect the creation when your commit has been merged in the release branch.

The package's README.md file must describe the releases like this example:

## Changelog

### v0.1.2

describe the release like you want

### v0.1.1

describe the release like you want

### v0.1.0

describe the release like you want

only the title '## Changelog' and the next title '###' will be catched
Order your releases from most recent to the oldest

How to contribute

Hello guys, thanks for you interest.

Before contribute, you can open an issue to explain your problem(s) and your solution(s). If you prefer, you can contact me.

Process to contribute

Fork the repositry and submit your feature(s) on the pull request.

Please, respect the process to update package as musch as possible.

Contact

mohl.clauzade@gmail.com

Acknowledgements

Thanks for reading so far ;)

ymohl-cl/gopkg