semantic-release does not create new tag when renovate creates new update on same branch

[ifalex]

The scenarios is as follows:
We have renovate enabled for helm charts. If between the moment of creation the MR and the moment we decide to merge them (as we do this periodically), a new update appears (Let's say we have a chart version to 5.0.6 which is updated initially to 5.0.7 and during the week a 5.0.8 appears) semantic-release won't create any new development version, because renovate does not create a new commit (this is by renovate behavior unfortunately), therefore not seeing any new commit.
This limits us in testing new development updates. Is there any semantic-release configuration that we could use to modify this behavior?

[travi]

renovate updates its PRs by rewriting the history of its own branches. that means that the previous release is no longer in the history of that branch. semantic-release requires previous releases to be in the history of a release branch that is expected to release a follow-up release.

there is no officially supported workflow that is intended to be used for testing every possible contribution to a project. the pre-release workflow is often used for use-cases beyond the intended purpose, but what you describe is not a supported workflow. semantic-release is for automating releases to consumers, not publishing releases to determine if it is safe to publish a release to a consumer. instead, we encourage taking steps to build enough confidence from automated tests to follow continuous integration without the need to publish a test release.