[
https://issues.jenkins-ci.org/browse/JENKINS-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162287#comment-162287
]
jglick commented on JENKINS-13457:
--
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.)
> support for hg flow
>
>
> Key: JENKINS-13457
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13457
> Project: Jenkins
> Issue Type: New Feature
> Components: mercurial
>Reporter: Joe Passavanti
>Assignee: Kohsuke Kawaguchi
> Labels: hgflow, mercurial
>
> 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:
> # query hg branches and look for any branches under the branch named in the
> above config variable
> ## if its the releases branch, there should always only be 0 or 1 according
> to hg flow
> ## if 0, nothing for jenkins to do
> ## if more than 1, some kind of process problem, jenkins shouldn't continue
> # assuming there is a branch under releases, switch to it
> # run hg update on the branch
> ## 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)
> ## if not, don't process rest of job
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira