<div dir="ltr"><div dir="ltr">On Sun, Dec 1, 2024 at 9:24 AM Ingo Klöcker <<a href="mailto:kloecker@kde.org">kloecker@kde.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Samstag, 30. November 2024 11:41:12 Mitteleuropäische Normalzeit Albert <br>
Astals Cid wrote:<br>
> El dissabte, 30 de novembre del 2024, a les 4:29:22 (Hora estàndard del<br>
> Centre d’Europa), Ben Cooksley va escriure:<br>
> > The two options I can see for resolving this are:<br>
> > a. Making use of the "ci.skip" Git push option when pushing a new work<br>
> > branch to be used in a merge request<br>
> > b. We set CI jobs as manual by default on work/ branches (optionally<br>
> > making<br>
> > use of a CI environment variable to allow work branches to run by default)<br>
> > <br>
> > I wouldn't be in favour of making the CI jobs disabled by default on work<br>
> > branches as that is non-intuitive / non-obvious behaviour, especially if<br>
> > you have to pass an environment variable to make them show up.<br>
> <br>
> How is it non-obvious? You created a "work" branch so no automatic CI for<br>
> you, if you want one, create a Merge Request (so you show your work to the<br>
> rest of us) or run the CI manually.<br>
<br></blockquote><div><br></div><div><div>By disabled I was referring to the jobs not being generated at all - so you would simply not receive a CI pipeline at all.</div></div><div>I don't think that is something we want to do, as the only way to switch it on would be by using an environment variable.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For the CD jobs we already do this. They are only run automatically on our <br>
mainline branches. Option b would merely extend this to all jobs for branch <br>
pipelines. The non-obvious part is that one has to know the KDE-specific CI/CD <br>
variable that one has to pass to change the behavior.<br></blockquote><div><br></div><div>Yes, and given how much we're reliant on CI i'm reluctant to change this behaviour too much.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Option a could also be a workable solution. We could recommend to set ci.skip <br>
as default option via `git config set push.pushOption ci.skip`. This option <br>
behaves pretty sensible: "Skips only branch pipelines and not merge request <br>
pipelines." i.e. it does exactly what we want. And people should be able to <br>
trigger a branch pipeline by using `git push -o ""`, i.e. by passing an empty <br>
push option. Granted it's not super intuitive.<br>
<br>
I'm leaning toward option a because it leaves the choice to the users using a <br>
standard option offered by GitLab.<br>
<br>
I have now added this option to my KDE specific .gitconfig file which I include <br>
in the global ~/.gitconfig with<br>
```<br>
[includeIf "gitdir:~/dev/kde/"]<br>
        path = ~/dev/kde/.gitconfig<br>
```<br>
<br>
Another alternative would be to define an alias, e.g.<br>
alias.push-mr=push -o ci.skip -o merge_request.create<br></blockquote><div><br></div><div>The alias seems reasonably workable / problem free from my perspective, although it does need action on the developer side.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Ingo<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>