Commits not triggering release #177
Comments
|
I've also noticed issues in Bitbucket Pipelines. The following commit message will not work and end up in that the analyzer states that no new release is necessary. Meanwhile, the non-squashed version of the commit message works perfectly fine.
v17.1.1 Configuration looks as follows: Set it up according to the semantic-release official documentation. edit: since writing this post, we've managed to get it working with Bitbucket Pipelines. Unfortunately, I don't recall the exact steps we took. But, the lesson here should be that the documentation isn't bulletproof enough in its current state. |
|
I’ve pretty much the same config and my commits are not recognised
|
|
@pvdlg Do you have any idea? |
|
@borisrorsvort directly in the output that you posted, it says "This run was not triggered in a known CI environment, running in dry-run mode". As mentioned in the docs, dry-run skips the |
|
@alehar9320 it looks like the troublesome commit that you mention has a subject of "Merged in topic/alhase-test-semantic-release (pull request #8)", which does not contain the details necessary for semantic-release to trigger a release. i'm having a hard time finding it now, but this has been brought up before and appears to be behavior that is specific to gitlab when doing that type of merge. our standard recommendation is to reach out to gitlab support to determine if there is a way to configure this behavior or request a change on their side. |
|
@vinothdevelop i believe your issue is most likely related to your attempt to switch from using |
|
@travi it won't push the realease but the dry-run still logs everything as if it would. I have the exact same stuff on CI. |
|
@borisrorsvort i don't spot a simple answer based on that output. is there a public build that you can point to that has this behavior, or a public repo showing your config? could you please run a build using the |
|
Here you go: |
|
Ok, I think that looks as I would expect. What version of semantic-release and plugins are installed? Could you ensure that multiple versions of each are not installed (using |
|
@borisrorsvort have you tried without a custom config file? the config you define above mostly aligns with the default config, so i'm curious if it works properly with the default config. |
|
No double version. I’m using SM v17.1.2. Tried with default config, still the same: |
|
@travi I really don’t see what it could be. Did you find anything strange with the logs? |
|
sorry for the slow response. i really dont see anything that i would expect to result in this behavior. with
i would not expect to see
for the various its a bit of a reach, but the most realistic thing i can come up with is some sort of character encoding issue or different character in there that looks like the expected character preventing the parsing of the commit from behaving as expected. i use semantic-release with the default config every day on various packages and have never seen behavior like this. i think the only way for me to be able to help more is with a minimal public project that reproduces the problem. this could help in two ways:
|
|
I once ammended my release commit and caused the release tag to be distached - that broke subsequent releases. |
|
I have the same problem, commit and pushes directly to main works as expected. But branching out on github and doing a pull request gives this Github prepends the commit message auomatically, so we have some junk |
|
Yeah, quite certain it's the squash commit that gives a format it can't handle. If doing a merge-commit of the feat-branch: if doing a squash-merge (estimated output) |
|
Same problem here, with what seems like squash commit issues as well: |
|
+1 how can we setup commit-analyzer for squashed commits? |
|
regarding squashed commits, semantic-release not processing the contents of the commit body to find the list of commits that were squashed is expected behavior. see https://semantic-release.gitbook.io/semantic-release/support/troubleshooting#squashed-commits-are-ignored-by-semantic-release for more detail |
|
It seems that the semantic-release authors have an opinion on squash merges and don't want to handle squash merges. It would be wonderful if somebody would fork this project and add such a feature as it's clear that this is a valid use case even if it doesn't meet the evangelism goals of the semantic-release authors. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current behavior
Using the following .releaserc file
{
"branches": ["main"]
}
I have tried multiple commits including Breaking Change none of them are triggering. Not sure if this is a bug or a configuration issue, please advice.
Expected behavior
Expecting a release
Environment
semantic-release version: Running semantic-release version ^17.1.1
CI environment: Github action (see link above)
Plugins used: -
semantic-release configuration: https://github.com/contactvinoth89/HTMLReport4Jest/blob/main/.releaserc
CI logs: https://github.com/contactvinoth89/HTMLReport4Jest/runs/961783213?check_suite_focus=true
The text was updated successfully, but these errors were encountered: