On Fri, Dec 3, 2021 at 8:53 AM Michael Reeves wrote:
> Where are the artifacts being uploaded to? They don't seem to show in
> gitlab. In particular the coverage report is of interest to me.
>
They are uploaded to Gitlab itself, but as reports so only some parts of
Gitlab's functionality show th
Hi everyone,
as part of the GitLab transition in Plasma we changed our commit
strategy from committing to stable and merging to master to committing
to master and cherry-picking to stable. Reason being that it's a lot
more convenient to do from GitLab's UI. I can merge and cherry-pick all
fro
Hi everyone,
I noticed that in some projects, probably those that trialed GitLab
before it was rolled out completely, have different configuration
options set to the rest of KDE, most notably "Delete source branch"
being off for new MRs.
Can you please check your repositories and make sure t
Hi Kai Uwe,
Last time I tried, rebasing in the UI was an GitLab enterprise feature. Not
sure what we use in KDE.
I searched for a source to back this up, and found that you can rebase with a
comment /rebase
See
https://docs.gitlab.com/ee/topics/git/git_rebase.html#rebase-from-the-gitlab-ui
Bye
We have rebasing in the UI in our CE instance.
Nate
On 12/3/21 11:06, Christoph Grüninger wrote:
Hi Kai Uwe,
Last time I tried, rebasing in the UI was an GitLab enterprise feature.
Not sure what we use in KDE.
I searched for a source to back this up, and found that you can rebase
with a com
Git commit 3e2d23469b401a1013efef0eb7f479a3bf328898 by Ben Cooksley.
Committed on 03/12/2021 at 18:40.
Pushed by bcooksley into branch 'master'.
Ensure that the option to 'Delete source branch' is enabled by default on all
new Merge Requests.
CCMAIL: kde-devel@kde.org
M +2-0maintenance
Where are the artifacts being uploaded to? They don't seem to show in
gitlab. In particular the coverage report is of interest to me.
On Sat, Nov 27, 2021 at 1:31 PM Ben Cooksley wrote:
> Hi all,
>
> As mentioned in the subject, i'm happy to announce the general
> availability of native Gitlab C
I have almost always merged stable to master, following the
documentation at https://community.kde.org/Infrastructure/
GitLab#Switching_the_target_branch_of_a_Merge_Request
Most of what I do is fixing bugs or warts in PIM, so I debug on the
release/* branch, and commit there to get the changes o
On 3/12/21 21:21, Glen Ditchfield wrote:
I have almost always merged stable to master, following the
documentation at https://community.kde.org/Infrastructure/
GitLab#Switching_the_target_branch_of_a_Merge_Request
Most of what I do is fixing bugs or warts in PIM, so I debug on the
release/* bran
I don't have any insights into any technical blockers, but if it is
technically feasible, I think it would be good to move everything to the
cherry-pick model due to the following advantages:
1. Unlike the merge-stable-to-master workflow, cherry-picking can be
done from the GitLab web UI, whic
Hi everyone,
+my 2 cents: I prefer merging from stable to master because it doesn't
require me to know which commits should be ported.
On Fri, Dec 3, 2021 at 9:20 PM Nate Graham wrote:
>
> I don't have any insights into any technical blockers, but if it is
> technically feasible, I think it woul
11 matches
Mail list logo
