Several build services parse commit messages containing "[skip ci]" as a way to not start a build after push. Is there any interest in having this added to scm.sr.ht?
If so, would submit.py be the place to add it?
https://git.sr.ht/~sircmpwn/scm.sr.ht/tree/master/scmsrht/submit.py
Thanks,
Jason
Jason,
There is substantial interest in it. There is a ticket lying around somewhere... I had started looking into it a while ago and that seems to be where I was looking as well.
Tristan Partin
Jason Staten <code@jxs.me> writes:
> Several build services parse commit messages containing "[skip ci]" as> a way to not start a build after push. Is there any interest in having> this added to scm.sr.ht?
While I can understand the need for such a feature, it seems weird to
encode this in a commit message, doesn't it? Maybe it's the only way?
>> If so, would submit.py be the place to add it?>> https://git.sr.ht/~sircmpwn/scm.sr.ht/tree/master/scmsrht/submit.py>> Thanks,> Jason
--
Malcolm Matalka
Abiogenesis Computer Systems Lab
Hello,
> > Several build services parse commit messages containing "[skip> > ci]"> > as a way to not start a build after push. Is there any interest in> > having this added to scm.sr.ht? > > While I can understand the need for such a feature, it seems weird to> encode this in a commit message, doesn't it? Maybe it's the only way?
I have seen people submitting additional information with push before,
I believe it was the '--push-option/-o' option, which runs a hook
'hooks/{pre,post}-receive'.
So it would be: git push -o skip-ci
This would be a better way in my opinion, because it does not make
sense to have "[skip ci]" as part of the repository history/commit
message.
Kind regards,
--
Humaid AlQassimi
https://humaidq.ae
> I have seen people submitting additional information with push> before,> I believe it was the '--push-option/-o' option, which runs a hook> 'hooks/{pre,post}-receive'.> > So it would be: git push -o skip-ci> > This would be a better way in my opinion, because it does not make> sense to have "[skip ci]" as part of the repository history/commit> message.
Agreed. You don't want your commit history to be polluted with
[skip ci] tags, and implementing this as a push option allows you to
skip builds without having to edit other people's commit messages (e.g.
when adding patches from others.)
> So it would be: git push -o skip-ci> > This would be a better way in my opinion, because it does not make> sense to have "[skip ci]" as part of the repository history/commit> message.
Agreed. I think push options would be the best way to implement these
kind of features. You don't want your repository's commit history to be
polluted with [skip ci] tags, and implementing this as a push option
lets you skip builds without having to edit other people's commit
messages when adding patches.
I agree it’s not ideal, but it is a common convention.
As an alternative that doesn’t clutter history, GitLab supports ignoring via the “ci.skip” git push option:
git push --push-option=ci.skip
I’m not sure what the Mercurial equivalent would be.
https://git-scm.com/docs/git-push#Documentation/git-push.txt---push-optionltoptiongthttps://docs.gitlab.com/ee/ci/yaml/#skipping-jobs> On Nov 6, 2019, at 3:04 AM, Malcolm Matalka <malcolm.matalka@acsl.se> wrote:> > > Jason Staten <code@jxs.me> writes:> >> Several build services parse commit messages containing "[skip ci]" as>> a way to not start a build after push. Is there any interest in having>> this added to scm.sr.ht?> > While I can understand the need for such a feature, it seems weird to> encode this in a commit message, doesn't it? Maybe it's the only way?> >> >> If so, would submit.py be the place to add it?>> >> https://git.sr.ht/~sircmpwn/scm.sr.ht/tree/master/scmsrht/submit.py>> >> Thanks,>> Jason> > > --> Malcolm Matalka> Abiogenesis Computer Systems Lab
I've just tested, Sourcehut CI currently will not skip the CI task if
commit message contains "[skip ci]", for example, commit message being
"[skip ci] chore: CI tasks".
If "git push" contains "-o" flag, for example, "git push -o skip-ci",
the CI task will indeed be skipped (thanks Humaid!).
The "-o" flag approach seems perfect - commit messages are clean - but
it doesn't work when user has no control over "git push" flags, like in
"lerna version".
Lerna pushes behind the scenes and currently only allows to customise
the git message so a commit message-based solution seems the only
possible approach in my case.
I think it's in Sourcehut's best interest to support "[skip ci]" (or
something equivalent) because redundant builds waste the resources and
the more ways to prevent that the better. In my case, if I don't cancel
manually, the redundant build eventually fails, but tests train still
runs for quite a while.
I'm nobody, but I love how simple and deterministic builds is. One can
always set up a task that check the commit message and quit early or
nest everything in the opposite condition.
Am Montag, 30. November 2020, 08:05:15 CET schrieb Nguyễn Gia Phong:
> One can> always set up a task that check the commit message and quit early or> nest everything in the opposite condition.
This also seems like the right approach for me and does not require any code
on the sr.ht side of things.
Just my 2ct.
--
Matthias