Azure Pipelines - Pull Request Inheritance #1579
Comments
|
This is the exact issue I'm facing. It recursively calls itself until it overflows. |
|
We are seeing the same issue now with no configuration changes on our side. It only started recently. |
|
Which version of GitVersion are you experiencing this with? Have you tried upgrading to the latest v5 beta? |
|
For our part, we are using the latest available on Azure DevOps which is version 4.* or so it says. We had to put in an option to not look further back in the history than Jan 01 '19 for ours and then it started working again. Not sure why it would choke like that on previous commits. |
|
It's very hard to know without being able to reproduce the problem. A public repository portraying this issue would help immensely. |
|
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions. |
|
I solved this issue in Azure DevOps by configuring the pull-request matching regex to catch the ADO PR branch #'s and to not increment. pull-request:
mode: ContinuousDelivery
tag: PullRequest
increment: **None**
prevent-increment-of-merged-branch-version: false
tag-number-pattern: '[/-](?<number>\d+)[-/]'
track-merge-target: false
regex: (pull|pull\-requests|pr|[0-9]+)[/-]
tracks-release-branches: false
is-release-branch: falseIt's a quick hack for sure and won't account for everything probably needed. |
|
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions. |
|
Great find, @samjwest. A PR that adjusts the default regex of GitVersion to also match AzDO's out of the box would be welcome. |
|
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions. |
|
I'm also hitting this on my pipeline Azure pipeline (using GitHub as source) But don't understand why or how exactly the workaround would fix it. But in the builds it fails with
I don't want to turn off the increment :/ Even with the warnings it appears to be setting the version numbers correctly My build log: |
|
Are there any future plans in looking into this? I see it was marked stale by the bot, but this is still an issue for myself. |
|
@owns, as I don't use AzDO myself, nothing is going to happen until someone who actually needs this submits a PR, as noted in #1579 (comment). |
|
@asbjornu Thank you for clarifying. |
|
@asbjornu can you see my comment? I don't see how the regex change would help as it is actually matching the pull request rule already as it can be seen by the name of the version it generated. |
|
@joaorosado, I think the real problem here is AzDO failing on warnings being logged and not on the exit code of the executing process. Or is the exit code of GitVersion actually non-zero in this case? Anyhow, if changing the logged statement from We just need a PR from someone who can verify that this indeed fixes the problem. |
|
Yes, like you said, it doesn't cause the pipeline itself to fail, only marks all builds with warnings. I can give it a try to fix it, but doesn't look like changing that line will be enough. The "WARN [05/18/20 22:03:11:35] Failed to inherit Increment branch configuration, ended up with: master, origin/master" looks like the real culprit here. |
|
I've just experienced a similar warning on a local build, directly in my VS2019 output (speaking of develop instead of master, but otherwise, same symptom). I have no GitVersion configuration at all. |
|
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions. |
Hi, It can be argued that this isn't Azure DevOps, but to me it looks the same as the issue that is described. However, the version numbering is correct (at least for my project), so I really think this shouldn't be a warning, but a info. Another solution might be to ignore local branches from the calculations and only use a specified remote branch? |
|
This issue is all about the following line within the class this.log.Info($"No branch configuration found for branch {targetBranch}, falling back to default configuration");The branch configuration system and the way how the branch inheritance happend has been changed. The hole class has been removed with the actual development initiaitives in version 6.x. Thus I'm going to close this issue. Please re-open this issue if this problem sill persists. Thank you very much. |
|
🎉 This issue has been resolved in version 6.0.0-beta.2 🎉 Your GitReleaseManager bot 📦🚀 |
I'm using a trunk-based branching strategy that I'm trying to version using the GitVersion@4 task in Azure Devops. All works perfectly fine when building off feature branches, but Pull Request builds don't appear to be inheriting properly. The flow we have is:
feature/bug -> PR -> master -> release
In the log I can see it's using the feature/bug branch itself a base - should it not be the pull request branch?
The text was updated successfully, but these errors were encountered: