Details

    • Similar Issues:

      Description

      hg flow (https://bitbucket.org/yinwm/hgflow/wiki/Home) adds process control in Mercurial similar to git flow (https://github.com/nvie/gitflow). One of the outcomes of this process is that it creates and deletes branches all the time.

      For example: the "releases" branch in itself really doesn't have anything in it. In our process, we have mapped this to staging, so that, when we create a release, hg flow will create a branch under releases with whatever name we come up with. example: releases/rel_12

      Once we deem this release as tested and ready to go live, hg flow will then merge it into the default (sometimes known as master) branch, which is where we then push out to our servers for production.

      It would be nice, if the Jenkins Mercurial plugin could help match this process. As it is today, when we create a new release, I have Jenkins set up with a parameter for the job, that we have to type in the current release branch every time we push an update. It would be nice if there could a checkbox or job config that would tell jenkins which of the top branches to monitor (releases,default,develop, etc.). Then the process would go as:

      1. query hg branches and look for any branches under the branch named in the above config variable
        1. if its the releases branch, there should always only be 0 or 1 according to hg flow
        2. if 0, nothing for jenkins to do
        3. if more than 1, some kind of process problem, jenkins shouldn't continue
      2. assuming there is a branch under releases, switch to it
      3. run hg update on the branch
        1. if there are updates, process updates, run rest of job, capture the branch name (example: rel_15 for the branch releases/rel_15) and allow it to be a variable for post build actions (example: to be used with Jira plugin to tag tickets with the release branch for Jira changelog)
        2. if not, don't process rest of job

        Attachments

          Activity

          Hide
          jglick Jesse Glick added a comment -

          This request is more specific and idiosyncratic than what the Mercurial plugin generally can support. Would need to be in its own plugin. The architectural question then is what can be programmatically reused from the basic Hg plugin. Can you create an SCM on the fly for a job and do some polling/updates/etc. with it? Or do you need to define your own SCM which delegates some functions?

          (JENKINS-11102 would cover some of the basic parts of this request.)

          Show
          jglick Jesse Glick added a comment - This request is more specific and idiosyncratic than what the Mercurial plugin generally can support. Would need to be in its own plugin. The architectural question then is what can be programmatically reused from the basic Hg plugin. Can you create an SCM on the fly for a job and do some polling/updates/etc. with it? Or do you need to define your own SCM which delegates some functions? ( JENKINS-11102 would cover some of the basic parts of this request.)

            People

            • Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              joepcds Joe Passavanti
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: