[gmx-developers] Transition to Gitlab

[Rebecca Kleemann]

Hi,

I'm about to start my bachelor thesis about adding a group for atoms 
with constant velocity to gromacs. Would it be possible to join Gromacs' 
GitLab?

Cheers,
Rebecca



Am 13.08.19 um 20:55 schrieb Erik Lindahl:
> Hi,
>
> Just to follow up on this discussion - I've spent quite a bit of time 
> both looking into GitLab workflows and customizing the gitlab-runner 
> CI client to our needs.
>
> 1) I've created patches for a handful of modifications:
>  a) Allow individual jobs to ask for custom resources (so e.g. builds 
> might use more cores than tests).
>  b) Support for GPU resources, including per-job and with artefacts 
> (e.g. binaries) propagated between jobs so we can compile a CUDA build 
> on any host, and only request GPU(s) for the tests.
>  c) I have extended the support for ccache so it is stored per merge 
> request branch, and if no previous branch cache is available we copy 
> it from master. This means virtually all builds can use ccache.
>
> 2) For the workflows, as mentioned before I do see a huge advantage 
> both with a relatively clean git log (without an extra merge commit 
> for every real commit) and also having all commits in master branch 
> compile. The best way to achieve this is with the fast-forward merge 
> only combined with squashing the change on merge.
>  a) For anything that is not fast-forwardable, this will require 
> rebasing. However, the good news is that this rebasing appears to be 
> at least as simple as our current one. One can either keep working on 
> an older version of a change and rebase when everything else is ready, 
> or rebase continuously just like we do now.
>  b) When pushing to the merge request branch, we just do "git push 
> --force-with-lease origin <branch>", and it will update the branch 
> without overwriting anybody else's modifications by mistake.
>  c) The merge request itself will keep track of the different 
> versions, so we can check what changed due to rebasing.
>
>
> At least initially I think it's good not to change our workflow too 
> much while changing environment, but we can of course revisit that 
> later - it's only a simple setting to alter in GitLab.
>
> So, here's my suggestion: To avoid causing sudden last-minute pain for 
> everyone, we stick with the present system through September 15 when 
> we release the beta. Some time (shortly) after that there might be up 
> to a week (hopefully only 2-3 days) when take things down and do the 
> move to GitLab.
>
> Cheers,
>
> Erik
>
>
>
>
>
>
>
>
>
>
> -- 
> Erik Lindahl <erik.lindahl at dbb.su.se <mailto:erik.lindahl at dbb.su.se>>
> Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm 
> University
> Science for Life Laboratory, Box 1031, 17121 Solna, Sweden
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20190917/2e9d05f1/attachment.html>