New SCMSource trait: filtering old git references

[Javier Delgado]

Following this comment, I was planning on creating a new scm trait for excluding references according to a date threshold.

The idea after the trait would be leaving out from an analysis branches considered deprecated or unmantained. This way, a new github organization or bitbucket team project wouldn't create jobs for the whole references sitting at the repository but just for the recent ones.

With this, the implementation seems it could be easy as hell, define a class extending from SCMSourceTrait that would add a (pre)filter according the defined threshold value. Here comes my question and request for help:

* Does anyone feel this would be an invaluable feature or doable in other way?

I cant seem to be able to look for a commit creation date. I can get the SHA1 for a branch tip via org.kohsuke.github.GHBranch$Commit and  com.cloudbees.jenkins.plugins.bitbucket.api.BitbucketBranch. From where could I extract the modification time of this commit? 

What seems true is that I cant apply a SCMSourceContext prefilter so this trait wont avoid trips to the Github API

[Stephen Connolly]

On 30 August 2017 at 01:03, Javier Delgado <witoko...@gmail.com> wrote:

Following this comment, I was planning on creating a new scm trait for excluding references according to a date threshold.

The idea after the trait would be leaving out from an analysis branches considered deprecated or unmantained. This way, a new github organization or bitbucket team project wouldn't create jobs for the whole references sitting at the repository but just for the recent ones.

With this, the implementation seems it could be easy as hell, define a class extending from SCMSourceTrait that would add a (pre)filter according the defined threshold value. Here comes my question and request for help:

* Does anyone feel this would be an invaluable feature or doable in other way?

I know there are users who would buy you beers if you implemented it for them.

There are other users who couldn't care less, which is why this will need to be an extension plugin not part of the core plugins

 

I cant seem to be able to look for a commit creation date. I can get the SHA1 for a branch tip via org.kohsuke.github.GHBranch$Commit and  com.cloudbees.jenkins.plugins.bitbucket.api.BitbucketBranch. From where could I extract the modification time of this commit? 

What seems true is that I cant apply a SCMSourceContext prefilter so this trait wont avoid trips to the Github API

Yep I think you will be hitting round-trips.

I am fine with adding supporting changes to the GitHub Branch Source plugin to add lazy caches to the request object... my rule is 

* Core plugin PRs that enable extension plugins are yes. Stuff that could be an extension plugin should not go in core. 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5c30e3f7-7acb-4268-9d6c-c6bd91103304%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Javier Delgado]

Of course, I was expecting this trait to be included in a separate plugin (WIP already on https://github.com/witokondoria/git-aged-refs-trait-plugin)

Those caches arent already implemented? What I feel I'm lacking is the commit date (and might be solved via the bitbucket and github api components)

El miércoles, 30 de agosto de 2017, 13:10:00 (UTC+2), Stephen Connolly escribió:

On 30 August 2017 at 01:03, Javier Delgado <witoko...@gmail.com> wrote:

Following this comment, I was planning on creating a new scm trait for excluding references according to a date threshold.

The idea after the trait would be leaving out from an analysis branches considered deprecated or unmantained. This way, a new github organization or bitbucket team project wouldn't create jobs for the whole references sitting at the repository but just for the recent ones.

With this, the implementation seems it could be easy as hell, define a class extending from SCMSourceTrait that would add a (pre)filter according the defined threshold value. Here comes my question and request for help:

* Does anyone feel this would be an invaluable feature or doable in other way?

I know there are users who would buy you beers if you implemented it for them.

There are other users who couldn't care less, which is why this will need to be an extension plugin not part of the core plugins

 

I cant seem to be able to look for a commit creation date. I can get the SHA1 for a branch tip via org.kohsuke.github.GHBranch$Commit and  com.cloudbees.jenkins.plugins.bitbucket.api.BitbucketBranch. From where could I extract the modification time of this commit? 

What seems true is that I cant apply a SCMSourceContext prefilter so this trait wont avoid trips to the Github API

Yep I think you will be hitting round-trips.

I am fine with adding supporting changes to the GitHub Branch Source plugin to add lazy caches to the request object... my rule is 

* Core plugin PRs that enable extension plugins are yes. Stuff that could be an extension plugin should not go in core. 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

[Stephen Connolly]

On Thu 31 Aug 2017 at 08:37, Javier Delgado <witoko...@gmail.com> wrote:

Of course, I was expecting this trait to be included in a separate plugin (WIP already on https://github.com/witokondoria/git-aged-refs-trait-plugin)

Those caches arent already implemented? What I feel I'm lacking is the commit date (and might be solved via the bitbucket and github api components)

I am not sure if the info you need is in one of the cached objects or not.

If it is already present, WIN!

If not present, I am happy to review PRs  on the "core" plugins that enable the feature.

El miércoles, 30 de agosto de 2017, 13:10:00 (UTC+2), Stephen Connolly escribió:

On 30 August 2017 at 01:03, Javier Delgado <witoko...@gmail.com> wrote:

Following this comment, I was planning on creating a new scm trait for excluding references according to a date threshold.

The idea after the trait would be leaving out from an analysis branches considered deprecated or unmantained. This way, a new github organization or bitbucket team project wouldn't create jobs for the whole references sitting at the repository but just for the recent ones.

With this, the implementation seems it could be easy as hell, define a class extending from SCMSourceTrait that would add a (pre)filter according the defined threshold value. Here comes my question and request for help:

* Does anyone feel this would be an invaluable feature or doable in other way?

I know there are users who would buy you beers if you implemented it for them.

There are other users who couldn't care less, which is why this will need to be an extension plugin not part of the core plugins

 

I cant seem to be able to look for a commit creation date. I can get the SHA1 for a branch tip via org.kohsuke.github.GHBranch$Commit and  com.cloudbees.jenkins.plugins.bitbucket.api.BitbucketBranch. From where could I extract the modification time of this commit? 

What seems true is that I cant apply a SCMSourceContext prefilter so this trait wont avoid trips to the Github API

Yep I think you will be hitting round-trips.

I am fine with adding supporting changes to the GitHub Branch Source plugin to add lazy caches to the request object... my rule is 

* Core plugin PRs that enable extension plugins are yes. Stuff that could be an extension plugin should not go in core. 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5c30e3f7-7acb-4268-9d6c-c6bd91103304%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f497407d-c330-47a2-968a-06eede877c11%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Sent from my phone

[Javier Delgado]

Stephen, could you pay a visit to https://github.com/witokondoria/branch-source-aged-refs-traits, to go on with the traits work? Have finaly gone through the path of one repo per trait, a module for each implementation (even there will be dummy releases when adding a new implementation)

Some of my concerns are related to the maven-enforcer checks (adding unrelated dependencies seems weird) and the "tests" (they just perform form load validation?) copied from the bitbucket-branch-source-plugin