Continuum
  1. Continuum
  2. CONTINUUM-2591

Git based maven2 builds can't properly release or checkout on branch

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.3.6
    • Fix Version/s: 1.4.1
    • Component/s: Release
    • Labels:
      None

      Description

      It is not possible to add or release a maven2 project using the git scm when the project is on a branch. There appears to be multiple reasons for this:

      • The maven-scm version bundled with continuum is old and doesn't include git providers with sufficiently complete git support.
      • Git SCM URLs don't include sufficient information to identify the branch.
      • Continuum-release's UpdateWorkingCopyPhase doesn't properly update the working (it always uses master rather than the current branch)
      1. CONTINUUM-2591.patch
        15 kB
        Brent N Atkinson
      2. CONTINUUM-2591-trunk.patch
        8 kB
        Brett Porter
      3. CONTINUUM-2591-trunk-2.patch
        6 kB
        Brent N Atkinson

        Activity

        Hide
        Brent N Atkinson added a comment -

        The attached patch illustrates a crude workaround for the issues prevent checkout and release from a branch.

        Show
        Brent N Atkinson added a comment - The attached patch illustrates a crude workaround for the issues prevent checkout and release from a branch.
        Hide
        Brent N Atkinson added a comment -

        Once the maven-scm git provider is updated, as long as the pom includes the proper 'tag' attribute in the scm metadata, continuum (actually maven-scm) can properly checkout the project and switch to the branch named in the 'tag' attribue.

        Show
        Brent N Atkinson added a comment - Once the maven-scm git provider is updated, as long as the pom includes the proper 'tag' attribute in the scm metadata, continuum (actually maven-scm) can properly checkout the project and switch to the branch named in the 'tag' attribue.
        Hide
        Brett Porter added a comment -

        the patch doesn't apply cleanly to trunk, mostly because it's already been updated to a newer maven-release version. I'm not sure I understand your second comment - are you saying that this is already right in maven-scm trunk?

        Show
        Brett Porter added a comment - the patch doesn't apply cleanly to trunk, mostly because it's already been updated to a newer maven-release version. I'm not sure I understand your second comment - are you saying that this is already right in maven-scm trunk?
        Hide
        Brett Porter added a comment -

        here's a naive application of the patch to trunk. I haven't checked it works yet - it seemed odd to be changing the method signatures when trunk had approached it differently (I think by delegating some of the methods). It needs a closer look, but I ran out of time.

        It's better to address patches to trunk - the 1.3.x releases should be small, and we're overdue to get a 1.4.1 out anyway...

        Show
        Brett Porter added a comment - here's a naive application of the patch to trunk. I haven't checked it works yet - it seemed odd to be changing the method signatures when trunk had approached it differently (I think by delegating some of the methods). It needs a closer look, but I ran out of time. It's better to address patches to trunk - the 1.3.x releases should be small, and we're overdue to get a 1.4.1 out anyway...
        Hide
        Brent N Atkinson added a comment -

        Brett, my apologies. A portion of the issue was solved by updating the maven-scm providers to 1.4 (so it should be right in trunk too). However, updating the working copy during release still didn't work right. During the working copy update phase the maven-scm update() call isn't passed the proper ScmVersion for the current working copy. It always is called with null. The git scm provider assumes that means you want to pull changes from master rather than the working copy's active branch (which seems rather odd to me, but I stepped around it). It essentially does a merge of two (possibly unrelated) branches.

        I should have made it more clear that the patch was only meant to illustrate the issue and is a crude workaround and not a complete fix. I fully expected that someone with more understanding of this process could improve it greatly. I based it on 1.3.6 because it is the non-beta release and it can get users around the problem. Next time, I'll submit a patch for trunk and the current non-beta release. Would that work?

        Show
        Brent N Atkinson added a comment - Brett, my apologies. A portion of the issue was solved by updating the maven-scm providers to 1.4 (so it should be right in trunk too). However, updating the working copy during release still didn't work right. During the working copy update phase the maven-scm update() call isn't passed the proper ScmVersion for the current working copy. It always is called with null. The git scm provider assumes that means you want to pull changes from master rather than the working copy's active branch (which seems rather odd to me, but I stepped around it). It essentially does a merge of two (possibly unrelated) branches. I should have made it more clear that the patch was only meant to illustrate the issue and is a crude workaround and not a complete fix. I fully expected that someone with more understanding of this process could improve it greatly. I based it on 1.3.6 because it is the non-beta release and it can get users around the problem. Next time, I'll submit a patch for trunk and the current non-beta release. Would that work?
        Hide
        Brett Porter added a comment -

        yep, I understand. I actually think the technique is quite acceptable (we have special cases for other SCMs around too), perhaps best if a concurrent patch is submitted to SCM so that it can be cleaned up as soon as the next release of that happens.

        As for patching trunk & branch - that's certainly helpful in getting it applied to both, with the priority being for trunk since it always has to land there anyway. In this case, because of the scope of the change (upgrading libraries / crude fix), I think it's better not to apply it to 1.3.x and instead focus on pushing for a non-beta 1.4 release soon

        Show
        Brett Porter added a comment - yep, I understand. I actually think the technique is quite acceptable (we have special cases for other SCMs around too), perhaps best if a concurrent patch is submitted to SCM so that it can be cleaned up as soon as the next release of that happens. As for patching trunk & branch - that's certainly helpful in getting it applied to both, with the priority being for trunk since it always has to land there anyway. In this case, because of the scope of the change (upgrading libraries / crude fix), I think it's better not to apply it to 1.3.x and instead focus on pushing for a non-beta 1.4 release soon
        Hide
        Brent N Atkinson added a comment -

        Attached slightly modified patch that works on trunk.

        Show
        Brent N Atkinson added a comment - Attached slightly modified patch that works on trunk.
        Hide
        Brett Porter added a comment -

        did you intend to apply this to trunk now?

        Show
        Brett Porter added a comment - did you intend to apply this to trunk now?
        Hide
        Brent N Atkinson added a comment -

        I didn't only because there are still limitations with the git-scm that make this a little weird. For instance, the tag element in the scm configuration in the pom isn't updated it doesn't track things properly, but it does solve the release/checkout issue.

        Show
        Brent N Atkinson added a comment - I didn't only because there are still limitations with the git-scm that make this a little weird. For instance, the tag element in the scm configuration in the pom isn't updated it doesn't track things properly, but it does solve the release/checkout issue.
        Hide
        Brett Porter added a comment -

        should we just drop it into the backlog for the time being?

        Show
        Brett Porter added a comment - should we just drop it into the backlog for the time being?
        Hide
        Brent N Atkinson added a comment -

        It might be good to integrate it as it grants git users the ability to use continuum in a normal work flow. I can integrate into trunk as long as no one opposes. Barring that, backlog is ok.

        Show
        Brent N Atkinson added a comment - It might be good to integrate it as it grants git users the ability to use continuum in a normal work flow. I can integrate into trunk as long as no one opposes. Barring that, backlog is ok.
        Hide
        Brett Porter added a comment -

        no objections here

        Show
        Brett Porter added a comment - no objections here
        Hide
        Brent N Atkinson added a comment -

        Committed in r1091054

        Show
        Brent N Atkinson added a comment - Committed in r1091054

          People

          • Assignee:
            Unassigned
            Reporter:
            Brent N Atkinson
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development