Description

There will be a strategy to use switch the checkout to over SSH and this will have a option to select the SSH Credentials for checkout.

There will be at least one strategy to subset the branches by name (include / exclude)

There will one implementation that uses the existing wildcard style

Other strategies may be added later to support different branch name matching rules, e.g. Regex, etc. These secondary strategies do not form part of the MVP but it may prove assist extension point API validation to proof-of-concept implement a second one.

There will be three strategies to subset the branches by type:

There will be a strategy to select origin branches. This strategy will have a drop-down mode selection:

Only origin branches that are not filed as PRs

Only origin branches that are filed as PRs

All origin branches irrespective of whether filed as PR or not

There will be a strategy to select origin PRs. This strategy will have a drop-down mode selection:

Merge commit PRs

Head commit PRs

Both merge commit and head commit PRs

There will be a strategy to select fork PRs. This strategy will have a drop-down mode selection:

Merge commit PRs

Head commit PRs

Both merge commit and head commit PRs

There will also be a drop-down for trust selection:

Show all fork PRs but only trust fork PRs from repository contributors

Only show PRs from repository contributors

Show and trust all fork PRs TBD determine if we need to expose suppression of automatic builds of untrusted PRs here.

There will be a proof-of-concept implementation of a tag support branch selector. This is not a feature experienced by users today, but there are api's & code which is ready to provide it. We won't ship this enabled by default in the release.

There will be the ability to control a subset of the Git plugin’s additional behaviours for the generated SCM of branches. This will be an applies to all setting. The available options will be subject to a whitelisting extension point (so that plugins can define additional Git behaviours and whitelist them in at the same time). The default whitelist will be:

Advanced Checkout behaviours

Advanced Clone behaviours

Advanced Submodule behaviours

Clean after checkout

Clean before checkout

Custom user name / email address

Git LFS pull after checkout

Use commit author in changelog (says it requires workspace polling, but really does not / should not require workspace polling)

Wipe out repository & force clone

Acceptance criteria

The SCM API provides the concept of a trait that applies to SCMSource and SCMNavigator

Traits will be opt-in, i.e. the SCMSource implementation must be written to use traits

Common trait implementations can be shared by multiple implementations.

Trait implementations can be specific to a single SCMSource or SCMNavigator

The SCM API will provide a trait implementation that allows for filtering branches based on include/exclude wildcard name matching

The SCM API MockSCM implementation will support traits

The common trait implementations in SCM API will have tests

The implementers guide will be updated to highlight the trait style of implementation and encourage following that path.

(the object instance itself is returned, but with all its field
instances recreated... something that I was trying to fix inhttps://github.com/jenkinsci/jenkins/pull/2736 but I hit issues.
I am switching to the more explicit comparison as future-proofing
for when the underlying issue in jenkins-core#2736 is fixed in
order to ensure that the test remains valid)

SCM/JIRA link daemon
added a comment - 2017-06-14 10:14 Code changed in jenkins
User: Stephen Connolly
Path:
src/test/java/jenkins/scm/impl/SingleSCMSourceTest.java
http://jenkins-ci.org/commit/scm-api-plugin/5f3fe479dd36e24ac4202eb2ffa2e66ddc256e0c
Log:
JENKINS-43507 Bobby didn't believe the test was real
(the object instance itself is returned, but with all its field
instances recreated... something that I was trying to fix in
https://github.com/jenkinsci/jenkins/pull/2736 but I hit issues.
I am switching to the more explicit comparison as future-proofing
for when the underlying issue in jenkins-core#2736 is fixed in
order to ensure that the test remains valid)

BlueOcean continually destroys and recreates the SCMNavigator without round-tripping through stapler form-binding
consequently it does not pick up the legacy default discovery traits.

Also found a trait duplication bug in GitHubSCMSource that was missed due to a faulty test but caught when replicating
the new legacy constructor tests from navigator into source 'just to be sure to be sure'

SCM/JIRA link daemon
added a comment - 2017-06-22 05:52 Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMNavigator.java
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMNavigatorTraitsTest.java
src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSourceTraitsTest.java
http://jenkins-ci.org/commit/github-branch-source-plugin/394d016d15970d1abf9f085f63dea741137ad4bc
Log:
JENKINS-43507 Legacy constructor needs to apply default discovery behaviours
BlueOcean continually destroys and recreates the SCMNavigator without round-tripping through stapler form-binding
consequently it does not pick up the legacy default discovery traits.
Also found a trait duplication bug in GitHubSCMSource that was missed due to a faulty test but caught when replicating
the new legacy constructor tests from navigator into source 'just to be sure to be sure'

So how are you supposed to use this change?
I have updated to the GitHub Branch Source plugin v2.2.1, which according to the release note, incorporates this change.
If I add a behaviour to specify the refspec, it gets ignored.
Is there another shoe to drop in order to get this behaviour, or is this a bug?

John Mellor
added a comment - 2017-07-19 18:25 So how are you supposed to use this change?
I have updated to the GitHub Branch Source plugin v2.2.1, which according to the release note, incorporates this change.
If I add a behaviour to specify the refspec, it gets ignored.
Is there another shoe to drop in order to get this behaviour, or is this a bug?

Stephen Connolly
added a comment - 2017-07-19 18:51 John Mellor So when you added the additional refspec, was that refspec fetched when cloning?
The additional refspec is not to define new branches or discovery of branches, rather to control what gets cloned (hence why it's not in the – Repository – section)

John Mellor
added a comment - 2017-07-19 18:58 - edited > So when you added the additional refspec, was that refspec fetched when cloning?
We're specifying a refspec of:
+refs/tags/*:refs/remotes/@{remote}/tags/*
and expecting it to pull tags. We can see no evidence in the log that this added refspec does anything at all. What should we be seeing?

John Mellor
added a comment - 2017-07-20 13:19 We tried the advanced behaviour as suggested, and it does not pull tags.
You can't request tags, only ignore tags, suggesting pulling tags is a default.
So, how are you supposed to build a GitHub tag?

Stephen Connolly
added a comment - 2017-07-20 13:46 Requesting tags is adding the behaviour and not selecting "ignore tags"
Tag discovery has not been implemented yet, so likely you are trying to do something that would be better handled through tag discovery

Alexandru Pătrănescu
added a comment - 2017-07-20 14:15 Tag discovery has not been implemented yet
So this is the missunderstanding
Stephen, do you have a plan or a JIRA issue for implementing this?
Thanks

Trever Wilhelm
added a comment - 2017-07-24 21:41 Similar to John Mellor 's question, I need tags when checking out our repo in our pipeline scripts. Our current checkout step is simply
checkout scm
I don't understand from the previous posts how to add tags to this step

Stephen Connolly
added a comment - 2017-07-24 23:01 Trever Wilhelm you need to configure the branch source and just add Advanced Clone Behaviours and then checkout scm will automatically get the tags for you

There is an issue when building pull requests and the clone trait is present with shallow clone option.
Apparently you need some history in order to be able to do a merge.
I'm using the Bitbucket Server but I guess this is the same for GitHub...

How can we fix this?
a) Disable shallow clone when we know a merge will take place.
b) Fetch more and more history until you are able to do the merge, checking with merge-base command I guess.

Can we do this only in one place, maybe in hudson.plugins.git.extensions.impl.PreBuildMerge#decorateMergeCommand? or is it specific to each branch-source-plugin?

Alexandru Pătrănescu
added a comment - 2017-07-25 08:44 Hi,
There is an issue when building pull requests and the clone trait is present with shallow clone option.
Apparently you need some history in order to be able to do a merge.
I'm using the Bitbucket Server but I guess this is the same for GitHub...
How can we fix this?
a) Disable shallow clone when we know a merge will take place.
b) Fetch more and more history until you are able to do the merge, checking with merge-base command I guess.
Can we do this only in one place, maybe in hudson.plugins.git.extensions.impl.PreBuildMerge#decorateMergeCommand ? or is it specific to each branch-source-plugin?

Stephen Connolly
added a comment - 2017-07-25 08:53 Alexandru Pătrănescu can you create a separate issue for that.
Likely we need to go with Disable shallow clone when we know a merge will take place
For now, that needs to happen in each plugin, but we could refactor https://github.com/jenkinsci/github-branch-source-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github_branch_source/MergeWithGitSCMExtension.java and it's copies into the Git plugin and switch to use that (and have that turn off shallow clone)
But all that should take place under a separate JIRA from this

I think this issue, which is marked as minor, contains a massive breaking change, i.e. above-mentioned fetching without tags. I have just spent almost a day trying to figure out why my builds no longer work.

This started to surface as a build error when referring to a tag that didn't exist, then progressing to figure out that where previously my scm step executed with git fetch --tags, it is now executing with git fetch --no-tags, and then a wild goose chase of trying to downgrade various plugins that were upgraded recently, including the branch source plugin, the pipeline plugin, the pipeline scm plugin, and also the git plugin (which didn't work because other plugins depended on it).

I also went down the route of trying to change our Jenkinsfile which is using "checkout scm" step to try and specify more configuration options, all without success.

To prevent other users being led on this merry chase, I strongly recommend that you make it exceedingly clear that this new feature causes a regression whereby builds that previously fetched with tags now don't.

It is also very unintuitive and unclear that adding "Advanced clone options" without checking any of its flags or filling out any of its properties magically restores the fetch with tags behaviour.

It is unexpected that adding something without configuring it would change the behaviour.

Development tools should lead users into the pit of success, not the pit of failure (and despair!). Please reconsider the impact of this change, or alternatively add a big fat warning for users upgrading to this version that their builds will behave differently now.

Thanks for the wonderful tool that Jenkins is, and all the great work on the main server, this, and other plugins.

Riko Eksteen
added a comment - 2017-07-25 13:23 - edited I think this issue, which is marked as minor, contains a massive breaking change, i.e. above-mentioned fetching without tags. I have just spent almost a day trying to figure out why my builds no longer work.
This started to surface as a build error when referring to a tag that didn't exist, then progressing to figure out that where previously my scm step executed with git fetch --tags, it is now executing with git fetch --no-tags, and then a wild goose chase of trying to downgrade various plugins that were upgraded recently, including the branch source plugin, the pipeline plugin, the pipeline scm plugin, and also the git plugin (which didn't work because other plugins depended on it).
I also went down the route of trying to change our Jenkinsfile which is using "checkout scm" step to try and specify more configuration options, all without success.
I eventually searched google for the string "Cloning with configured refspecs honoured and without tags" from my build output, which led me to https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/extensions/impl/CloneOption.java, and finally this thread.
To prevent other users being led on this merry chase, I strongly recommend that you make it exceedingly clear that this new feature causes a regression whereby builds that previously fetched with tags now don't.
It is also very unintuitive and unclear that adding "Advanced clone options" without checking any of its flags or filling out any of its properties magically restores the fetch with tags behaviour.
It is unexpected that adding something without configuring it would change the behaviour.
Development tools should lead users into the pit of success, not the pit of failure (and despair!). Please reconsider the impact of this change, or alternatively add a big fat warning for users upgrading to this version that their builds will behave differently now.
Thanks for the wonderful tool that Jenkins is, and all the great work on the main server, this, and other plugins.

Patrick Rose
added a comment - 2017-07-25 14:53 This is also causing issues for us because the "checkout to subdirectory" option has now been removed. Is there a workaround for that or do I need to handle this manually?

Stephen Connolly
added a comment - 2017-07-25 15:29 "Checkout to subdirectory" caused other problems and the correct solution in multibranch has always been to just do
dir( 'subdir' ){
checkout scm
}
instead of
checkout scm
The extensions that were exposed by mistake have been removed to prevent the bugs that people were encountering

Intentional changes from JENKINS-43507 have reduced server load, disc
use, and data transfer by honor the refspec which matches the branch of
the job being built in a multi-branch pipeline, and by not fetching tags.

Unfortunately, this branch contains tests which assume it is operating
with a complete clone of the repository, including all tags and all
branches.

The tests have been fixed on the master branch, but not on this branch.
Rather than fix the tests on this branch (with the risk that creates),
this change modifies the clone to include all history and all tags.

SCM/JIRA link daemon
added a comment - 2017-07-27 23:58 Code changed in jenkins
User: Mark Waite
Path:
Jenkinsfile
http://jenkins-ci.org/commit/git-client-plugin/5cff403b221f58106d85edfcaa2d6ae90a1bc9e0
Log:
Clone repo with all history and all tags
Intentional changes from JENKINS-43507 have reduced server load, disc
use, and data transfer by honor the refspec which matches the branch of
the job being built in a multi-branch pipeline, and by not fetching tags.
Unfortunately, this branch contains tests which assume it is operating
with a complete clone of the repository, including all tags and all
branches.
The tests have been fixed on the master branch, but not on this branch.
Rather than fix the tests on this branch (with the risk that creates),
this change modifies the clone to include all history and all tags.

This change – that tags are no longer included by default – also broke all of our builds.

We are using the Github multi-branch Organization plugin. I keep seeing reference to "Advanced clone options" – with a cropped screenshot. Where is this UI? Is it supposed to be on the configuration page for the Github Organization, because I can't find it.

We have about 500 github projects that all depend on git tags being present during the build. Do we have to change all of our builds "checkout scm" lines in all builds to add these options?

Its a big task to change them all, and also breaks the ability to build old versions of code without any modifications.

If there is any ability to go back to the old behavior via a global setting, that would be greatly appreciated. I can not find the referenced UI in the screenshot anywhere under system configuration or Github Organization configuration.

Greg Smith
added a comment - 2017-07-28 20:23 This change – that tags are no longer included by default – also broke all of our builds.
We are using the Github multi-branch Organization plugin. I keep seeing reference to "Advanced clone options" – with a cropped screenshot. Where is this UI? Is it supposed to be on the configuration page for the Github Organization, because I can't find it.
We have about 500 github projects that all depend on git tags being present during the build. Do we have to change all of our builds "checkout scm" lines in all builds to add these options?
Its a big task to change them all, and also breaks the ability to build old versions of code without any modifications.
If there is any ability to go back to the old behavior via a global setting, that would be greatly appreciated. I can not find the referenced UI in the screenshot anywhere under system configuration or Github Organization configuration.

OK – Sorry, i was able to find that UI now, via "Add" under "Behaviors" on the github organization UI.

We added that to our Github organization configuration. Should that automatically fix all builds using a simple "checkout scm" in their pipeline code? As we have seen no change in behavior or resolution to the problem yet after adding that extra configuration.

Greg Smith
added a comment - 2017-07-28 20:32 - edited OK – Sorry, i was able to find that UI now, via "Add" under "Behaviors" on the github organization UI.
We added that to our Github organization configuration. Should that automatically fix all builds using a simple "checkout scm" in their pipeline code? As we have seen no change in behavior or resolution to the problem yet after adding that extra configuration.
Under what conditions are those additional behaviors used?

Riko Eksteen We had called out the change in the way the Git SCM Source checks out:

The GitHub and Bitbucket plugins both inherit their per-branch checkout behaviour from the Git plugin. I am sorry that it was not obvious that you should also pay attention to the class structure changes involved and that the exposure of the ability to configure all of the Git Branch Source's behaviours would now mean that you would get the new Git Branch Source defaults for checking out. Is there some text you think would be good to add to the GitHub Branch Source wiki page that would make this change more obvious?

Stephen Connolly
added a comment - 2017-07-31 10:01 Riko Eksteen We had called out the change in the way the Git SCM Source checks out:
The GitHub and Bitbucket plugins both inherit their per-branch checkout behaviour from the Git plugin. I am sorry that it was not obvious that you should also pay attention to the class structure changes involved and that the exposure of the ability to configure all of the Git Branch Source's behaviours would now mean that you would get the new Git Branch Source defaults for checking out. Is there some text you think would be good to add to the GitHub Branch Source wiki page that would make this change more obvious?

Stephen Connolly, thanks for your reply. Our process is usually as follows: Jenkins warns us about out-of-date plugins, we hit upgrade for the out-of-date plugins. But not before I go onto the release notes, as far as possible, and check what changed.

In this instance I think we upgraded from 3.3.2 to 3.4.1. Now that you have pointed out to me that you did specify the changes in the release notes, my take-away is this:

I should have read the release notes more carefully to make sure I understand what exactly had changed.

From my perspective, changing the plugin to to fetch without tags instead of with tags is a breaking change, it regresses the behaviour that myself - and other people, going by this thread - relied on.

If you agree with the former point (which you may not), in semver terms, a breaking change is a new major version, i.e. 4.0 as opposed to 3.x.

Irrespective of the above, in terms of the release notes, it would have been great if their was a clearly visible warning in the first line of the release notes indicating that some people may see unexpected behaviour, instead of that information being hidden away in a long paragraph towards the end. (I appreciate that this may only be evident in hindsight.)

Even now, when clicking through to the JIRA from the release notes, it is listed in the JIRA properties as a "minor" change, and appears to be quite innocuous, while being anything but - from my (extremely) limited understanding it is quite a major change that affect multiple interlocking plugins.

Riko Eksteen
added a comment - 2017-07-31 13:44 Stephen Connolly , thanks for your reply. Our process is usually as follows: Jenkins warns us about out-of-date plugins, we hit upgrade for the out-of-date plugins. But not before I go onto the release notes, as far as possible, and check what changed.
In this instance I think we upgraded from 3.3.2 to 3.4.1. Now that you have pointed out to me that you did specify the changes in the release notes, my take-away is this:
I should have read the release notes more carefully to make sure I understand what exactly had changed.
From my perspective, changing the plugin to to fetch without tags instead of with tags is a breaking change, it regresses the behaviour that myself - and other people, going by this thread - relied on.
If you agree with the former point (which you may not), in semver terms, a breaking change is a new major version, i.e. 4.0 as opposed to 3.x.
Irrespective of the above, in terms of the release notes, it would have been great if their was a clearly visible warning in the first line of the release notes indicating that some people may see unexpected behaviour, instead of that information being hidden away in a long paragraph towards the end. (I appreciate that this may only be evident in hindsight.)
Even now, when clicking through to the JIRA from the release notes, it is listed in the JIRA properties as a "minor" change, and appears to be quite innocuous, while being anything but - from my (extremely) limited understanding it is quite a major change that affect multiple interlocking plugins.
Thanks for taking the time to respond and reading my reply!

This new behaviour is just a nightmare for us, we have upgraded from 3.3.2 to 3.5.0.

About 2 days spent to try to repair our build based on tags push event and nothing is working as it should...

"Because each branch job in a multibranch project will only ever build the one specific branch, the default behaviour for a Git Branch Source is now to use a minimal refspec corresponding to just the required branch. Tags will not be checked out by default. If you have a multibranch project that requires the full set of ref-specs (for example, you might have a pipeline that will use some analysis tool on the diff with some other branch) you can restore the previous behaviour by adding the "Advanced Clone Behaviours". Note: In some cases you may also need to add the "Specify ref specs" behaviour."

This solution just solves nothing, i added the Advanced Clone Behaviours and the "Specify ref specs" and nothing happened the plugin still don't care about our tags. It would be really appreciate to have a clearly detailed sample about how to set your plugin to let it work with tags correctly.

Ludovic Mercier
added a comment - 2017-07-31 15:01 This new behaviour is just a nightmare for us, we have upgraded from 3.3.2 to 3.5.0.
About 2 days spent to try to repair our build based on tags push event and nothing is working as it should...
"Because each branch job in a multibranch project will only ever build the one specific branch, the default behaviour for a Git Branch Source is now to use a minimal refspec corresponding to just the required branch. Tags will not be checked out by default. If you have a multibranch project that requires the full set of ref-specs (for example, you might have a pipeline that will use some analysis tool on the diff with some other branch) you can restore the previous behaviour by adding the "Advanced Clone Behaviours". Note: In some cases you may also need to add the "Specify ref specs" behaviour."
This solution just solves nothing, i added the Advanced Clone Behaviours and the "Specify ref specs" and nothing happened the plugin still don't care about our tags. It would be really appreciate to have a clearly detailed sample about how to set your plugin to let it work with tags correctly.

Stephen Connolly
added a comment - 2017-07-31 15:31 Ludovic Mercier are you trying to build tags or are you trying to compare against tags?
If building tags, this is not yet supported (may have accidentally worked previously, but was not intended to work)
If comparing against tags, have you done a reindex first to update all the job configurations?

Ludovic Mercier
added a comment - 2017-08-01 07:16 Hi Stephen Connolly ,
Thanks for your time, We were building tags effectively and i must say it's not a good news to read that it shouldn't have worked.
It seems that we will have to change our strategy and workflow according to this or maybe you have a potential roadmap about this feature.

New tags might be interesting if the user wants to configure it that way

Interesting heads is not strictly required for branch-api as there is the ability to define a BranchBuildStrategy and that would allow suppressing automatic builds of tags on project creation (which is really the big issue for tags)

Support for implementing tags in the GitHub plugin is being tracked in JENKINS-34395, likely we'll just consolidate the Bitbucket, Git and Gitea implementations of the same feature under this banner

Stephen Connolly
added a comment - 2017-08-01 09:03 Ludovic Mercier so there are issues with building tags that need to be addressed:
We probably want the concept of interesting heads: JENKINS-45502
Old tags are not interesting for sure
New tags might be interesting if the user wants to configure it that way
Interesting heads is not strictly required for branch-api as there is the ability to define a BranchBuildStrategy and that would allow suppressing automatic builds of tags on project creation (which is really the big issue for tags)
Support for implementing tags in the GitHub plugin is being tracked in JENKINS-34395 , likely we'll just consolidate the Bitbucket, Git and Gitea implementations of the same feature under this banner
HTH

The refactoring itself is binary compatible but adds new methods. There are extensive tests of data migration. I believe there is only one use case where we missed a potentially breaking change, namely if you construct the SCMSource instance in your pipeline directly (e.g. for use with resolveScm) in all other cases the existing configuration should have been migrated:

If you have a migration data set that is not migrating correctly, then that is a bug which should be filed in a separate JIRA and we can add an additional test case for your configuration and then fix it

Stephen Connolly
added a comment - 2017-08-01 09:18 Riko Eksteen
it is listed in the JIRA properties as a "minor" change
Nope, it was listed as a PRIORITY of "minor", not a scope.
The refactoring itself is binary compatible but adds new methods. There are extensive tests of data migration. I believe there is only one use case where we missed a potentially breaking change, namely if you construct the SCMSource instance in your pipeline directly (e.g. for use with resolveScm ) in all other cases the existing configuration should have been migrated:
https://github.com/jenkinsci/github-branch-source-plugin/blob/f2a9fdd871e218429cd1de198b130596e90ee167/src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSourceTraitsTest.java#L107-L396 and https://github.com/jenkinsci/github-branch-source-plugin/blob/f2a9fdd871e218429cd1de198b130596e90ee167/src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSourceTraitsTest.java#L800-L1997
https://github.com/jenkinsci/github-branch-source-plugin/blob/f2a9fdd871e218429cd1de198b130596e90ee167/src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMNavigatorTraitsTest.java#L58-L1561
https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/master/src/test/java/com/cloudbees/jenkins/plugins/bitbucket/BitbucketSCMSourceTest.java#L57-L434
https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/e220b43404aca15574c7a9be3724a40587093414/src/test/java/com/cloudbees/jenkins/plugins/bitbucket/BitbucketSCMNavigatorTest.java#L53-L461
https://github.com/jenkinsci/git-plugin/blob/e08051a8e571f32887d463c72361123b6b37befb/src/test/java/jenkins/plugins/git/GitSCMSourceTraitsTest.java#L81-L211
If you have a migration data set that is not migrating correctly, then that is a bug which should be filed in a separate JIRA and we can add an additional test case for your configuration and then fix it

Wanted to follow up, and say that once that once we completed a full rescan of our org, the additional behaviors were copied down to each project, and the original behaviors were restored. This resolved all of our problems.

Several of the other featured included in this change are very handy, so I wanted to say thanks again, I think this change overall will be be very useful in the long term.

Greg Smith
added a comment - 2017-08-02 14:47 Wanted to follow up, and say that once that once we completed a full rescan of our org, the additional behaviors were copied down to each project, and the original behaviors were restored. This resolved all of our problems.
Several of the other featured included in this change are very handy, so I wanted to say thanks again, I think this change overall will be be very useful in the long term.