<div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>Just to follow up on this discussion - I&#39;ve spent quite a bit of time both looking into GitLab workflows and customizing the gitlab-runner CI client to our needs. </div><div><br></div><div>1) I&#39;ve created patches for a handful of modifications:</div><div> a) Allow individual jobs to ask for custom resources (so e.g. builds might use more cores than tests).</div><div> 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.</div><div> 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.</div><div><br></div><div>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. </div><div> 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.</div><div> b) When pushing to the merge request branch, we just do &quot;git push --force-with-lease origin &lt;branch&gt;&quot;, and it will update the branch without overwriting anybody else&#39;s modifications by mistake.</div><div> c) The merge request itself will keep track of the different versions, so we can check what changed due to rebasing. </div><div><br></div><div><br></div><div>At least initially I think it&#39;s good not to change our workflow too much while changing environment, but we can of course revisit that later - it&#39;s only a simple setting to alter in GitLab. </div><div><br></div><div>So, here&#39;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.</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl &lt;<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>&gt;</div><div>Professor of Biophysics, Dept. Biochemistry &amp; Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div></div></div></div></div></div>