Clone from Github
Tested versions of DAMASK are mirrored at GitHub/Eisenforschung/DAMASK.
DAMASK GitLab-Server for Developers
The full DAMASK repository is hosted at the DAMASK GitLab-Server at MPIE. You need an account to clone!
Request an Account
- If you want to contribute code, you need to approve the Contributor License Agreement, which you can download here.
- Please write an email with the CLA attached to damask-CLA@mpie.de stating your approval to request developer status in GitLab.
- Access via SSH and password does not work (a keyfile is required)
Set up git on your computer such that GitLab can recognize you:
git config user.name "FIRSTNAME LASTNAME"
git config user.email "A@B.DE"
in the DAMASK repository or
git config --global user.name "FIRSTNAME LASTNAME"
git config --global user.email "A@B.DE"
for a system-wide setup.
development is the branch that should always work (and
master of course as well). For any changes, create a new branch named after the feature you’re working on (or, contribute to an existing branch). For new features, create tests.
After finishing working on a branch, test the code. If it is working, request to merge it into development. Assign the merge request to one of the developers (other than you!). For a small bugfix to the latest commit, use
git commit --amend
In contrast to centralized version control systems such as SVN, their distributed counterparts offer a lot of flexibility in selecting a workflow model. https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow presents some possible workflows. A detailed discussion, including many links, can be found at http://stackoverflow.com/questions/2621610/what-git-branching-models-work-for-you
- DAMASK work flow
- Create a new branch for features and improvements.
- Once all changes are done, request to merge them into the
- After a successful test,
developmentis automatically merged into
- Releases are manually created from the
masterbranch and constitute the
DAMASK G MM.mm.ff.pppp ^^^^^^--------------------------- Name ^------------------------- Generation (skip for the moment) ^^---------------------- Major (not backward compatible, old input files will not work) ^^------------------- Minor (new features) ^^---------------- Bugfix ^^^^----------- Patch
For a fast feedback on any changes pushed to the http://magit1.mpie.de, modified files are checked before a push is accepted. This is done via a pre-receive hook. Python files are checked for invalid code, unused variables etc. using prospector. Prospector is a tool to analyze Python code and reports information about errors, potential problems, convention violations, and complexity and combines the functionality of other Python analysis tools. The configuration file DAMASK.yaml is designed to ensure compatibility with Python 2.x and Python 3.x. Any change in the src subdirectory triggers a syntax check with gfortran
-fsyntax-only for the grid solver; Any change in the src subdirectory triggers a syntax check with ifort
-fsyntax-only for MSC.Marc. To skip this check, add ‘[skip sc]’ to the final commit message, e.g. via
git commit -a --amend
in the case that all your changes are locally committed already.
Extended testing is performed on each push using the GitLab Continuous Integration. All tests specified in a configuration file in the main repository are run on the test server (nohup, using Damask_user). The pipelines give a feedback on which tests failed. To skip the tests, add ‘[skip ci]’ to the final commit message, e.g. via
git commit -a --amend
in the case that all your changes are locally committed already. If the test suite needs to be modified for a certain branch, the submodules feature of git allows to couple the status of the branch with a fitting commit in the PRIVATE repository. Initialize (i.e. clone) the PRIVATE repository via
git submodule update --init
Any change in PRIVATE needs to be committed/pushed as usual. As submodules are linked as commit IDs (hashes) and not as branches, after initialization you are in ‘detached head’ mode and need to check out the branch of interest (typically ‘master’). Additionally, commit the current commit ID of the PRIVATE repository in the DAMASK repository:
git commit PRIVATE
By that, the status (i.e. the current commit ID) is stored in the current branch of the DAMASK repository and will be used by the test facility. https://docs.gitlab.com/ce/ci/git_submodules.html