Hi @mmomper,

Thank you for submitting this feature request. I've been dwelling on what is the best course of action here. I can understand the need for PSR providing some level of triggering support for skip ci flags.

My hesitation with your recommended implementation is that we support more than one hosted version control system (HVCS) and my cursory look is that GitHub does not support push options but GitLab does. I have not looked into Gitea or BitBucket's compatibility yet but that could be different as well. This leads me to consider a configuration option that basically defines which type of skip ci do you want to apply (push options or a commit message label). I personally don't quite want to get into the game of just inserting arbitrary user command switches for every internal command we provide as it seems quite messy as we have a few of those already. It stands to question what is the benefit of the package in the first place, but I digress. This is one motivation to instead consider the action we apply and handle that use. I think skip CI is something PSR needs to be cognizant of as we are generally triggering secondary CI workflows and running from within a CI environment, generally.

Prior to reading up on push options, my recommendation would have been to use the commit_message configuration option to customize the commit message to include a [skip ci] entry which has wider support including GitLab. However, based on your comment below, you seem to have some hesitation here?

Adding [skip ci] to every commit has also impact on everything else referencing this commit (for example the tag).

Can you expand upon the problem with this?

When I work with GitLab CI, generally if I'm using a semantic-release tool in a job, then I use the workflow:rules directive to turn off CI pipelines on any tags via the $CI_COMMIT_TAG variable. This is how I would handle the tag environment so would a push-option on the git push tag be necessary? The commit would need the [skip ci] tag in the commit message if I am writing back to the repository to prevent a subsequent workflow.

Hi @codejedi365 ,

Thanks for the reply and thoughts about it. First of all, my issue with the [skip ci] in the message is the following:

When the new commit is created and pushed, the CI gets skipped, as intended. But when the Tag is created and pushed, the CI for the Tag is also skipped, which may be unintended. I read somewhere that, if this commit is the lates of an MR, the CI for the merge would also be skipped (not my use case but I think it is something to not forget about).

In my use case, I thought about triggering a CI run on Tags in which the package gets pushed to the JFrog we are using.

I would agree, creating a switch/config option for every push option is not a good practice since the supported options are not specified by Git but by the HVCS implementation. I thought about a generic flag/config like commit-push-option/tag-push-option, which then gets passed to the call. In this way, the user could add the options he wants for his HVCS and there is no need to implement all of them explicitly.

Of course this could be archived with not including [skip ci] and using rules to not trigger the back push, but this is something you always have to not forget and maybe include in a job template. In my opinion, the push option would be a cleaner solution for that.

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

Still in the backlog, haven't gotten back around to the implementation

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

Still in backlog

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

Still in backlog

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

Still in backlog