[
https://issues.jenkins-ci.org/browse/JENKINS-13116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastien Tardif updated JENKINS-13116:
---------------------------------------
Summary: Should be able to filter out natively changeset so that not
all SCMs need to re-code the same logic, and also needed filtered changeset
even outside SCM trigger code (was: Should be able to filter out changeset so
that not all SCMs need to re-code the same logic, and also needed filtered
changeset even outside SCM trigger code)
Description:
Running jobs has a list of changes, represented by
http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html#getChangeSet%28%29
We should have a way to filter out from the UI the result that getChangeSet
will return. Then the many SCM plug-ins could leverage that to exclude changed
path when using SCM trigger.
In many SCM like git, there is no easy way to checkout only a subset of the
repository. In other cases, the flexibility of excludes/includes expressions
could be lot more flexible than flexible SCM like SVN.
We have only a small project and we have already encounter two different use
cases where this would have helped a lot:
- Git SCM includes/excludes supported pattern was deficient
- There is no working plug-ins that can bypass a subordinate job if no relevant
changes occur (from the subset the subordinate job care about) following a
periodic execution of the master job. So I would like to have a 1 line script
calling getChangeSet instead of copy/pasting the same includes/excludes logic.
was:
Running jobs has a list of change, represented by
http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html#getChangeSet%28%29
We should have a way to filter out from the UI the result that getChangeSet
will return. Then the many SCM plug-ins could leverage that to exclude changed
path when using SCM trigger.
In many SCM like git, there is no easy way to checkout only a subset of the
repository. In other cases, the flexibility of excludes/includes expressions
could be lot more flexible than flexible SCM like SVN.
We have only a small project and we have already encounter two different use
cases where this would have helped a lot:
- Git SCM includes/excludes supported pattern was deficient
- There is no working plug-ins that can bypass a subordinate job if no relevant
changes occur (from the subset the subordinate job care about) following a
periodic execution of the master job.
> Should be able to filter out natively changeset so that not all SCMs need to
> re-code the same logic, and also needed filtered changeset even outside SCM
> trigger code
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JENKINS-13116
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13116
> Project: Jenkins
> Issue Type: Improvement
> Components: core
> Affects Versions: current
> Environment: All
> Reporter: Sebastien Tardif
>
> Running jobs has a list of changes, represented by
> http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html#getChangeSet%28%29
> We should have a way to filter out from the UI the result that getChangeSet
> will return. Then the many SCM plug-ins could leverage that to exclude
> changed path when using SCM trigger.
> In many SCM like git, there is no easy way to checkout only a subset of the
> repository. In other cases, the flexibility of excludes/includes expressions
> could be lot more flexible than flexible SCM like SVN.
> We have only a small project and we have already encounter two different use
> cases where this would have helped a lot:
> - Git SCM includes/excludes supported pattern was deficient
> - There is no working plug-ins that can bypass a subordinate job if no
> relevant changes occur (from the subset the subordinate job care about)
> following a periodic execution of the master job. So I would like to have a 1
> line script calling getChangeSet instead of copy/pasting the same
> includes/excludes logic.
--
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
