Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-10377

Repository has changed but Bamboo is unable to extract changes between revision X and Y

      Observed on CBAC, e.g. https://confluence-bamboo.atlassian.com/browse/CONFSTAB-CWD-119

      It seems to affect dependant builds. Event if sth. went wrong during SVN-> git migration the following builds should update planVcsRevisionHistory and this problem should've fixed itself.

            [BAM-10377] Repository has changed but Bamboo is unable to extract changes between revision X and Y

            Paul added a comment -

            We are seeing an intermittent problem in Bamboo v6.4.0 where a build is triggered but it shows :-

            Changes by [unknown]

            Bamboo was unable to extract changes between revision.

            Looking in the Bitbucket Server 4.14.3 log file there are intermittent commit indexing errors :-

            Insert into cs_repo_membership (cs_id, repository_id) was aborted: ERROR insert or update on table cs_repo_membership violates foreign key constraint fk_repo_membership_changeset

            Wondering if the Bitbucket database error is the cause of this.

            Paul added a comment - We are seeing an intermittent problem in Bamboo v6.4.0 where a build is triggered but it shows :- Changes by [unknown] Bamboo was unable to extract changes between revision. Looking in the Bitbucket Server 4.14.3 log file there are intermittent commit indexing errors :- Insert into cs_repo_membership (cs_id, repository_id) was aborted: ERROR insert or update on table cs_repo_membership violates foreign key constraint fk_repo_membership_changeset Wondering if the Bitbucket database error is the cause of this.

            This is happening in 5.8.1 and I am pretty sure it's due to rebasing and force push. Amend your tip commit, force push up the branch. Bamboo picks up the build but it is not able to detect the author and it results in this error.

            Robert Dailey added a comment - This is happening in 5.8.1 and I am pretty sure it's due to rebasing and force push. Amend your tip commit, force push up the branch. Bamboo picks up the build but it is not able to detect the author and it results in this error.

            Hi gcatto,
            If you open a https://support.atlassian.com/browse/BSP issue our Support team will assist you on fixing this.
            Esther

            sthr (Inactive) added a comment - Hi gcatto , If you open a https://support.atlassian.com/browse/BSP issue our Support team will assist you on fixing this. Esther

            Hi Esther,

            We are using Bamboo 5.4.1 build 4207 with Git repositories. I will double-check to ensure we ran the command correctly against the correct repositories, since there haven't been other reports of the workaround failing.

            As for seeing the comments on https://support.atlassian.com/browse/BSP-8209 , I do not seem to have access to that ticket.

            Thanks!

            Geoffrey Catto added a comment - Hi Esther, We are using Bamboo 5.4.1 build 4207 with Git repositories. I will double-check to ensure we ran the command correctly against the correct repositories, since there haven't been other reports of the workaround failing. As for seeing the comments on https://support.atlassian.com/browse/BSP-8209 , I do not seem to have access to that ticket. Thanks!

            Hi gcatto,
            It's the first report we have about the workaround not working properly. Which version of Bamboo are you running, and against which kind of repository?
            If you provide us a database dump, we could find out if you are affected by the known issue the workaround relates to, or another one. See how to do it in the comments of https://support.atlassian.com/browse/BSP-8209. Please feel free to open a https://support.atlassian.com/browse/BSP issue so we can assist you on this.
            Hope to hear back from you, and again sorry for the inconveniences!
            Esther (Bamboo Development team)

            sthr (Inactive) added a comment - Hi gcatto , It's the first report we have about the workaround not working properly. Which version of Bamboo are you running, and against which kind of repository? If you provide us a database dump, we could find out if you are affected by the known issue the workaround relates to, or another one. See how to do it in the comments of https://support.atlassian.com/browse/BSP-8209 . Please feel free to open a https://support.atlassian.com/browse/BSP issue so we can assist you on this. Hope to hear back from you, and again sorry for the inconveniences! Esther (Bamboo Development team)

            Esther,

            Thanks for your response! We've tried that fix, but it doesn't seem to work (or it stops working relatively quickly); we still get the same message from Bamboo about being unable to extract changes between revision X and Y.

            Are there other steps we can take?

            Thank you!

            Geoffrey Catto added a comment - Esther, Thanks for your response! We've tried that fix, but it doesn't seem to work (or it stops working relatively quickly); we still get the same message from Bamboo about being unable to extract changes between revision X and Y. Are there other steps we can take? Thank you!

            Hi gcatto,
            Sorry for the late reply. We're working on getting a proper fix, in the meantime you may apply the workaround proposed above:

            DELETE FROM PLAN_VCS_HISTORY WHERE PLAN_KEY = <plan_key>

            You can do it for every plan/job where the problem shows. The 1st change detection will fill in the right data into this table. After that, every subsequent change detection should properly report commits.

            Please feel free to reach us to let us know if this workaround helps or not. And sorry for any incovenciences!

            Esther

            sthr (Inactive) added a comment - Hi gcatto , Sorry for the late reply. We're working on getting a proper fix, in the meantime you may apply the workaround proposed above: DELETE FROM PLAN_VCS_HISTORY WHERE PLAN_KEY = <plan_key> You can do it for every plan/job where the problem shows. The 1st change detection will fill in the right data into this table. After that, every subsequent change detection should properly report commits. Please feel free to reach us to let us know if this workaround helps or not. And sorry for any incovenciences! Esther

            We are having this issue is well in some of our projects. Is there a way to fix or workaround it?

            Geoffrey Catto added a comment - We are having this issue is well in some of our projects. Is there a way to fix or workaround it?

            Marcin Gardias added a comment - - edited

            We are not sure what causes this problem.. One possible reason to this problem is incorrectly cleaned PLAN_VCS_HISTORY due to (fixed) bug in plan deletion code. If a customer was hit by that bug and happened to create a new plan with an old plan key, that can happen.

            My proposal:

            • add some defensive code around retrieving planVcsHistory checking if there's a mismatch in build numbers (next build number > build number of latest history item)
            • add some debugging logging that we can switch on if the problem repeats

            Marcin Gardias added a comment - - edited We are not sure what causes this problem.. One possible reason to this problem is incorrectly cleaned PLAN_VCS_HISTORY due to (fixed) bug in plan deletion code. If a customer was hit by that bug and happened to create a new plan with an old plan key, that can happen. My proposal: add some defensive code around retrieving planVcsHistory checking if there's a mismatch in build numbers (next build number > build number of latest history item) add some debugging logging that we can switch on if the problem repeats

            Getting some new reports coming in for 4.2, re-opening.

            James Dumay added a comment - Getting some new reports coming in for 4.2, re-opening.

              Unassigned Unassigned
              mgardias Marcin Gardias
              Affected customers:
              10 This affects my team
              Watchers:
              17 Start watching this issue

                Created:
                Updated:
                Resolved: