Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
Dunitrust
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
This is an archived project. Repository and other project resources are read-only.
Show more breadcrumbs
nodes
rust
Dunitrust
Commits
60b44722
Commit
60b44722
authored
7 years ago
by
Éloïs
Browse files
Options
Downloads
Plain Diff
Merge branch '15-write-contributing-doc' into 'dev'
Resolve "Write contributing doc" Closes
#15
See merge request
!12
parents
5af21406
2802edac
No related branches found
No related tags found
1 merge request
!12
Resolve "Write contributing doc"
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
CONTRIBUTING.md
+107
-0
107 additions, 0 deletions
CONTRIBUTING.md
with
107 additions
and
0 deletions
CONTRIBUTING.md
0 → 100644
+
107
−
0
View file @
60b44722
# Contributing
When contributing to this repository, please first discuss the change you wish to make via issue and
via the
[
forum
](
https://forum.duniter.org
)
before making a change.
Please note we have a specific workflow, please follow it in all your interactions with the project.
## Workflow
-
You must create an issue for each feature you wish to develop, with a precise title and a
description of your feature. Then, assign it to yourself and click on the button
**`Create a merge request`**
. GitLab will create a branch dedicated to the issue as well as a
*Work in Progress*
merge request of this branch into the main branch (
`dev`
).
-
Please use tags to specify feature domains and concerned crates.
-
Never contribute to a branch whose issue has not been assigned to you! If the contributor make a
`git rebase`
your commit will be lost !
-
Before you push your commit:
1.
Apply
`rustfmt`
. Only formatted code will be accepted, and gitlab-ci will make sure it is ok.
Some exceptions are accepted such as long raw strings.
`rustfmt` is a tool applying Rust idiomatic code style to your files automatically.
If you're using rust 1.24 or greater :
```bash
# Install rustfmt through rustup
rustup component add rustfmt
# Run rustfmt
cargo fmt
```
If you're using rust 1.23 or lower :
```bash
# Install nightly toolchain
rustup install nightly
# Install rustfmt through cargo
cargo +nightly install rustfmt
# Run rustfmt
cargo +nightly fmt
```
> If you switch from 1.23 to 1.24, uninstall `rustfmt` from cargo and install it back with
> `rustup`
1.
Use
`clippy`
.
`clippy` is a linting tool scanning your code to find common mistakes or bad code.
Currenctly `clippy` is only available on the `nigthly` toolchain.
```bash
# Install nightly toolchain
rustup install nightly
# Install clippy through cargo
cargo +nightly install clippy
# Run clippy
cargo +nightly clippy
```
1.
Document your code and avoid any unsafe feature.
Each create should contain in its root file
```rust
#![deny(missing_docs, missing_debug_implementations, missing_copy_implementations,
trivial_casts, trivial_numeric_casts, unsafe_code, unstable_features, unused_import_braces,
unused_qualifications)]
```
It forces you to write documentation for any public code and prevent you from using unstable
or unsafe code.
1.
Write unit tests, and verify that they
**all**
pass.
1.
Made a git rebase to make your history clean.
```bash
# Make an alias
git config --global alias.tidy "rebase -i @{upstream}"
# Rebase your last commits since last push
git tidy
```
## Merge Process
1.
Ensure any install or build dependencies are removed before the end of the layer when doing a
build.
1.
Ensure you rebased your branch on the latest
`dev`
commit to avoid any merge conflicts.
1.
Update the README.md with details of changes to the interface, this includes new environment
variables, exposed ports, useful file locations and container parameters.
1.
Increase the version numbers in any examples files and the README.md to the new version that this
Pull Request would represent. The versioning scheme we use is
[
SemVer
](
http://semver.org/
)
:
If the create is in developement stage, its format is 0.X.Y. In production stage, it's X.Y.Z.
- When a API breaking change is made, X must be incremented.
- If new features are added without breaking the API, Y must be incremented.
- If the change is a quick fix of a production version, Z is incremented.
Your crate should always start with 0.1.0 version and only pass in 1.0.0 when no big changes are
planned. There is no need to rush a 1.0.0, take your time :)
1.
You may merge the Merge Request in once you have the sign-off of two other developers. If you
do not have permission to do that, you may request the second reviewer to merge it for you.
\ No newline at end of file
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment