EDF development workflow

This section describes the adopted workflow for the continuous integration in the EDF repository.

Rules for EDF continuous integration

  • The main branch is main. Developers must not commit revisions in this branch.

  • Developers must use their own branch to commit changes: XY-feature (use your initials for XY).

  • Commit messages must refer to the an existing issue.

Configure your repository

Note

In the examples, the repositories paths are $HOME/dev/codeaster/src for src and $HOME/dev/codeaster/devtools for devtools.

  • Update the devtools repository:

    cd $HOME/dev/codeaster/devtools && hg pull && hg update default

  • Configure the URL of the remote repositories:

    cd $HOME/dev/codeaster/src
install_env
# or
$HOME/dev/codeaster/devtools/bin/install_env

    It should print something like:

    Configuring 'src' repository...
INFO     checking repository $HOME/data/dev/codeaster/src
INFO     settings added into $HOME/data/dev/codeaster/src/.hg/hgrc
INFO     checking repository $HOME/data/dev/codeaster/data
INFO     settings added into $HOME/data/dev/codeaster/data/.hg/hgrc
INFO     checking repository $HOME/data/dev/codeaster/validation
INFO     settings added into $HOME/data/dev/codeaster/validation/.hg/hgrc
INFO     checking repository $HOME/data/dev/codeaster/devtools
INFO     checking asrun preferences...
Do you want to automatically configure and build code_aster (y/n)? n
INFO     Instructions to build code_aster:
cd $HOME/data/dev/codeaster/src
./waf configure
./waf install

Development workflow

Note

Despite this documentation, rebase should be prefered.

See the example below (time is botton-up):

@    9:1ef6a397a16f main: merge 'mc-fix-cmd'
|\
| o  8:fbb270649f54 mc-fix-cmd: [#45678] Other fixes.
| |
| o  7:424270e8c082 mc-fix-cmd: [#45678] Add changes for the same feature
| |
| o  6:2fedc3797079 mc-fix-cmd: update to branch 'main'
|/|
o |  5:06487835c81e main: merge 'mc-fix-cmd'
|\|
| o  4:832106d39564 mc-fix-cmd: [#45678] Reopen same developer branch for new feature
|/
o    3:08f9c539e56e main: merge 'mc-fix-cmd'
|\
| o  2:cc027a3c53fb mc-fix-cmd: [#12345] Continue development for feature 12345
| |
| o  1:960aca07afbb mc-fix-cmd: [#12345] Start feature for 12345
|/
o  0:53c1e379e218 main: Main branch: main

  1. Start point should always be the main branch.

  2. Start branch (hg branch mc-fix-cmd) and hack code.

  3. Continue hacking and submit your work (hg submit).

  4. If the checkings pass, the robot automatically merges in the main branch.

  5. Reopen the branch from main for a new feature (hg update main && hg branch -f mc-fix-cmd). Code and submit changes (hg submit).

  6. If the checkings pass, the robot automatically merges in the main branch.

  7. Update working branch with last changes from main (hg update mc-fix-cmd && hg merge main && hg commit -m "update to branch 'main'").

  8. Additional developments are required, continue from the same branch.

  9. More changes and submission (hg submit).

  10. If the checkings pass, the robot automatically merges in the main branch.

Memo:

  • Reuse the same branch name.

  • Continue on the same branch if you continue on the same feature.

  • Reopen the branch from main for new feature (hg branch -f ...).

List of checkings

To be accepted, the developments must pass the following checkings.

  • Merge with main branch (main) should be trivial (checked by check_automerge.sh).

    In case of conflicts you have to merge the main branch with yours first. If your branch has several heads you have to merge them first.

  • Check sequential and parallel builds.

  • Check build of the embedded documentation (checked by check_docs.sh).

  • Check that sequential testcases are passed (submit testlist).

  • Check that parallel testcases are passed (submit testlist).

hg submit checks the same steps except the parallel build and the parallel testcases.

Source files are checked by aslint. Issues must be validated and changed documents must be submitted.