[gmx-developers] Transition to Gitlab

[Erik Lindahl]

Having said that, you're most welcome to join us :-)

Since we're putting the last touches to the 2020 beta we're a bit late with
the gitlab move - but I'll announce it here shortly!

Cheers,

Erik

On Tue, Sep 17, 2019 at 12:52 PM Berk Hess <hess at kth.se> wrote:

> Hi,
>
> The pull code can already do that with a constraint.
>
> Cheers,
>
> Berk
>
> On Sep 17, 2019 12:41, Rebecca Kleemann <rkleeman at students.uni-mainz.de>
> wrote:
>
> 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>
> Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm
> University
> Science for Life Laboratory, Box 1031, 17121 Solna, Sweden
>
>
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.



-- 
Erik Lindahl <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/99692417/attachment-0001.html>