Do's

Do Not's

Do Use it For:

Don't Use it For:

  • storing simulation/calculation codes, history, and changes
  • collaborate on code development
  • version controlled software, updates, bugs, issues, and feature requests
  • storing data or large files
  • storing passwords, .env files, server info, etc.
  • posting undocumented code
  • "One-off" analysis scripts
  • storing ECI code/files (need to verify this)

Do Put it on Gitlab:

  • New code to conduct specialized molecular simulations
  • A collection of scripts and analysis tools used to develop coarse-grained models from generic all-atom MD simulations
  • A custom plugin for a commercial software that enhances its functionality
  • Code that would be useful (either directly or as a reference) for other Solvay researchers
  • A custom PDE solver implemented in Matlab

Don't Put it on Gitlab:

  • Raw or post-processed data from simulations or calculations
  • A Python notebook used for final analysis of simulation data and figure generation
  • Slides or reports
  • Bash scripts used to submit HPC jobs

Repository Mirroring

See Gitlab Mirroring for more information

Why you should use a mirror

"Mirror a repository when:

  • The canonical version of your project has migrated to GitLab. To keep providing a copy of your project at its previous home, configure your GitLab repository as a push mirror. Changes you make to your GitLab repository are copied to the old location.
  • Your GitLab instance is private, but you want to open-source some projects.
  • You migrated to GitLab, but the canonical version of your project is somewhere else. Configure your GitLab repository as a pull mirror of the other project. Your GitLab repository pulls copies of the commits, tags, and branches of project. They become available to use on GitLab"

--https://docs.gitlab.com/ee/user/project/repository/mirror/

Best Practices

  • Mirrored repositories will only mirror protected branches
  • Mirrored branches will not record divergence (updates to protected branches on the mirror will be overwritten)
  • External collaborators should give us an access token or similar to the repository so that we can set up an internal mirror on our Gitlab repository
    • Potentially bidirectional if they are expecting us to push code changes 

Limitations

Currently only have push capabilities. This means downstream mirrors will not be able to update main repository

Our Repositories

A subgroup of Solvay-rni can be created with a support ticket with IT

Groups

https://gitlab.solvay.com/solvay-rni (all Solvay access)

https://gitlab.solvay.com/solvay-rni/sim-mod-network (all Solvay sim/mod access)

https://gitlab.solvay.com/solvay-rni/spp-physics (internal to polymer physics team)