Skip to content
Snippets Groups Projects
Select Git revision
  • 652e457b3296e21d016283f10868f26f95f06b64
  • master default protected
  • fix_picked_up_file_in_runtime_release
  • network/gtest-1000 protected
  • upgradable-multisig
  • runtime/gtest-1000
  • network/gdev-800 protected
  • cgeek/issue-297-cpu
  • gdev-800-tests
  • update-docker-compose-rpc-squid-names
  • fix-252
  • 1000i100-test
  • hugo/tmp-0.9.1
  • network/gdev-803 protected
  • hugo/endpoint-gossip
  • network/gdev-802 protected
  • hugo/distance-precompute
  • network/gdev-900 protected
  • tuxmain/anonymous-tx
  • debug/podman
  • hugo/195-doc
  • gtest-1000-0.11.1 protected
  • gtest-1000-0.11.0 protected
  • gtest-1000 protected
  • gdev-900-0.10.1 protected
  • gdev-900-0.10.0 protected
  • gdev-900-0.9.2 protected
  • gdev-800-0.8.0 protected
  • gdev-900-0.9.1 protected
  • gdev-900-0.9.0 protected
  • gdev-803 protected
  • gdev-802 protected
  • runtime-801 protected
  • gdev-800 protected
  • runtime-800-bis protected
  • runtime-800 protected
  • runtime-800-backup protected
  • runtime-701 protected
  • runtime-700 protected
  • runtime-600 protected
  • runtime-500 protected
41 results

docker-entrypoint

Blame
    • pini's avatar
      b6b77324
      docker: simplify duniter subcommand run (!135) · b6b77324
      pini authored and Hugo Trentesaux's avatar Hugo Trentesaux committed
      * docker: simplify duniter subcommand run
      
      When the first argument of the entrypoint is '--' then bypass the default
      configuration via environment variables and directly run duniter with the
      given parameters (after removing the '--').
      
      The affected scripts and documentation were updated.
      b6b77324
      History
      docker: simplify duniter subcommand run (!135)
      pini authored and Hugo Trentesaux's avatar Hugo Trentesaux committed
      * docker: simplify duniter subcommand run
      
      When the first argument of the entrypoint is '--' then bypass the default
      configuration via environment variables and directly run duniter with the
      given parameters (after removing the '--').
      
      The affected scripts and documentation were updated.
    git-conventions.md 6.46 KiB

    Duniter git conventions

    TL;DR summary of this page, workflow instructions

    The summary gives an overview of the rules described below. Reading it will help you to dive into the details.

    • draft work must be prefixed by "WIP" (work in progress)
    • the naming of final commits must comply with the template type(scope): action subject
    • one should communicate with developers through dedicated spaces
    • integrating a contribution can only be done via a merge request on our gitlab option and since the following critera are fullfilled
      • branch up to date with master branch (except hotfixes, see the hotfix section)
      • idiomatic code formatting, automated tests passed successfully
      • clean commit history, understandable and concise
      • contribution approved by a reviewer

    Naming commits

    Every commit must comply with conventional commit specification v1.0.0.

    The commit name has to be meaningful in the context of commit history reread. It should not make reference to a specific MR or discussion. Among other, commit history is used in changlogs and to track the project progress, that's why it has to be self-explanatory. If you have a new need, please contact the main developers to add a type together.

    Update strategy

    We only use rebases, merges are strictly fordbidden !

    Every time the master branch is updated, you must rebase each of your working branch on it. For each of them:

    1. Go on your branch
    2. Rebase on master with git rebase master
    3. If you see conflicts, fix them by editing the sources. Once it is done, you must:
      1. commit the files that were in conflict
      2. continue the rebase with git rebase --continue
    4. Keep doing until you don't have any more conflict after git rebase --continue.

    To prevent accidental merge commits, we recommend to force the --ff-only option on the merge command:

    git config --global merge.ff only

    When to push

    Ideally, you should push when you are about to shut down your computer, so about once a day.

    You must prefix your commit with wip: when it is a work in progress.

    But why push if I am not done ?

    Pushing is no big deal and prevents you from loosing work in case of any problem with your material.

    Before requesting proofreading of your merge request

    After complying with the above criteria in your commits, you should check that your branch is up to date with the target branch (master in this example). As this branch is moving forward frequently, it is possible that new commits may have occurred while you were working on your branch (named YOUR_BRANCH, here). If this is the case or in case of doubt, to update your branch with respect to master, do the following: