Gitlab Tips&Tricks ( Was: Transition to Gitlab Complete)

[Allen Winter]

Email filtering
 Automatically collect the pim merge requests in my PIM/Reviews folder
   setup a kmail filter on X-GitLab-MergeRequest and X-GitLab-Project-Path: pim

On Sunday, May 17, 2020 10:48:14 AM EDT Allen Winter wrote:
> go to https://invent.kde.org/pim and you can set the Watch for all pim projects at once
> (don't know if it works yet since there hasn't been any activity)
> 
> https://invent.kde.org/profile/notifications to set notifications on any of the top-level groups
> 
> I wanted to set the avatar for KOrganizer but I guess only the Maintainer can do that.
> I don't think any projects have been given Maintainership yet.
> 
> Please pass along any howtos/tips/tricks.
> 
> I'm excited and happy about this move.
> -Allen
> 
> ----------  Forwarded Message  ----------
> 
> Subject: Transition to Gitlab Complete
> Date: Sunday, May 17, 2020, 6:47:35 AM EDT
> From: Ben Cooksley <bcooksley at kde.org>
> To: kde-cvs-announce at kde.org, kde-devel <kde-devel at kde.org>
> 
> Good morning all,
> 
> Over the past 24 hours Sysadmin has been busy working on transitioning
> everything from git.kde.org over to invent.kde.org (Gitlab) a process
> which we have now essentially completed.
> All repositories with the exception of personal (scratch and clone)
> repositories have been migrated successfully now. We intend to migrate
> the remaining personal repositories over the coming week.
> 
> You should all be aware of the following:
> 
> -- Work Branches --
> 
> As part of the transition to Gitlab, we have also simultaneously
> rolled out work branches.
> 
> These are branches that live within the normal repositories, but do
> not have notification hooks triggered on them. This means that they
> will not close bugs, send email or be announced on IRC. As such, they
> can also be force pushed.
> Any branch prefixed with the name 'work/' is considered to be a work branch.
> 
> It is important to note that the server will enforce a maximum number
> of 100 commits divergence between a work branch and any other normal
> branch (those not prefixed with work/) in the repository.
> This is necessary to protect our systems when the work branch is
> merged to a normal/release branch (which is when the hooks will
> process all of those commits)
> 
> We therefore do not recommend work branches for long term work such as
> GSoC projects or other significant items of work - normal branches
> should be used for these.
> 
> All other branches will continue to be subject to normal commit hook
> processing, and cannot be force pushed.
> 
> -- Migration Helpers --
> 
> To assist with the migration to Gitlab, Sysadmin earlier mentioned a
> series of helper tools which could be used to clone repositories
> conveniently from Gitlab as well as migrate existing clones.
> 
> To set these up, you will need a clone of 'sysadmin/repo-metadata' on
> your local system, along with Python3 and PyYAML (packaged as
> python3-yaml on most distributions) installed on your system.
> Once you have these, add the folder 'git-helpers' in
> 'sysadmin/repo-metadata' to $PATH and you should be good to go.
> 
> Please note that 'git kpull' at the moment is only able to perform the
> initial migration from anongit.kde.org/git.kde.org to invent.kde.org
> urls.
> Additional patches to improve this are welcome.
> 
> -- Conclusion --
> 
> Apologies for the disruption this caused - please note that a number
> of systems that work closely with the Git repositories are in the
> process of catching up with the transition at the moment.
> During this time there may be some disruption to them, however we hope
> that this will all be completed over the coming week.
> 
> Should anyone have any questions regarding this, please let us know
> (via sysadmin at kde.org)
> 
> Thanks,
> Ben Cooksley
> KDE Sysadmin
> 
> -----------------------------------------
> 
> 
>