Hi all, Thanks for the responses! If there is no negative feedback, I will proceed with the implementation next Monday. Whomever wants to add any extra components to evaluation, please comment in this thread.
Jesse: Since the primary use case is offering updates to plugin > repositories, > I would suggest including at least one example of `*-plugin`. ..... if (a) > have fairly low installation count (b) are maintained by people actively > participating in the trial. > maven-hpi-plugin matches the wildcard :P Speaking seriously, we could try to add some Jenkins plugins to the experiment if (a) and (b) conditions are met. If Mark wants to try out his plugins Mark: Updates to non-test dependencies are not very helpful for me. When > dependabot suggests that the git plugin should rely on the latest release > of some other plugin, it risks placing unnecessary demands on users to > install newer plugins than are required. I tell dependabot to stop > offering those dependency updates. It closes the pull requests and stops > offering updates to that component. > Yes, dependabot can be controlled by GitHubCommentOps or Configuration-as-Code <https://dependabot.com/blog/introducing-config-files/>. It may require maintainers to set up filters, but then it will work like a charm. For evaluation purposes I would recommend configuration-as-code tho. It may help us to easily verify the configured filters later. Jesse: The question is which dependencies ought to be eligible for upgrade. > I do not think we want to update Jenkins core or plugin dependencies > gratuitously, since this would limit availability of new releases with only > modest productivity gain: more realistic functional tests, less distance > from `master` to whatever `plugin-compat-tester` would use. > Same as above, we could somehow configure it via filters somehow though it might be not trivial. I think that we will need to... 1. Document recommendations in JEP after the evaluation 2. Provide Config File samples (in JEP) so that maintainers can configure Dependabot correctly Maybe Dependabot can be configured to request me as a reviewer? > Yes, it can <https://dependabot.com/docs/config-file/#default_reviewers>. Best regards, Oleg On Thursday, February 21, 2019 at 5:21:36 PM UTC+1, Gavin Mogan wrote: > > Another one to look at is Renovate bot ( https://renovatebot.com/docs/ ) > > I suspect maven doesn't update nearly as often as node does, but i have > greenkeeper on a lot of my node projects, and sometimes when something > updates (like the testing framework) i get a huge number of PRs really > quickly. > > Renovate bot does have support for auto merging PRs if you want, so it can > handle things a little automated. > > But I'm +1 for Dependabot > > On Thu, Feb 21, 2019 at 8:10 AM R. Tyler Croy <[email protected] > <javascript:>> wrote: > >> >> I'm game for experimenting with this :D >> >> On Thu, 21 Feb 2019, Oleg Nenashev wrote: >> >> > Dear all, >> > >> > I would like to follow-up on the Dependabot request from Jesse Glick in >> > INFRA-1975 <https://issues.jenkins-ci.org/browse/INFRA-1975>. >> Dependabot >> > <https://dependabot.com/> is a service for automated dependency updates >> > which supports many languages/tools, including Maven, Docker and Gradle >> > which are being heavily used in Jenkins. >> > >> > Dependency management is a problem in Jenkins, because we have hundreds >> of >> > repositories with many dependencies there. Maintainers spend a lot of >> time >> > on managing dependencies, and sometimes it leads to ancient >> dependencies in >> > components. Especially in the development tools which "just work". By >> > automating dependency updates we could give maintainers more time to >> focus >> > on other tasks. >> > >> > Dependabot is one of the engines we could use for dependency >> management. It >> > is free for open-source projects, and it is a SaaS application which >> can be >> > almost completely managed from GitHub. It can just create pull requests >> or, >> > if we want, implement validated merge with help of ci.jenkins.io. No >> > special infrastructure required, and this is an advantage for us. There >> are >> > other implementations (including UpdateBot >> > <https://github.com/jenkins-x/updatebot> by Fabric8/Jenkins X which >> has a >> > Jenkins plugin), but it would require more efforts to deploy the >> > infrastructure. It could be considered in the future if we want to have >> > Jenkins-powered update management in the final implementation. >> > >> > My proposal would be to enable Dependabot for a *limited number* of >> Jenkins >> > repositories so that we can experiment with it. I propose to focus on >> > development tools and pre-1.0 projects only for now so that we can >> > experiment with flow without a risk of impact on components being used >> in >> > production in the Jenkins project. And we will be setting up >> auto-updates >> > only for projects with existing test automation. >> > >> > - Jenkinsfile Runner - Example PRs in my local repo >> > <https://github.com/oleg-nenashev/jenkinsfile-runner/pulls> >> > - ci.jenkins.io-runner - Example PRs >> > <https://github.com/jenkinsci/ci.jenkins.io-runner/pulls> (bot was >> > disabled after moving the repo) >> > - plugin-pom - Example PRs in my local repo >> > <https://github.com/oleg-nenashev/plugin-pom/pulls> >> > - maven-hpi-plugin - Example PRs in my local Repo >> > <https://github.com/oleg-nenashev/maven-hpi-plugin/pulls> >> > >> > More repositories can be added if somebody is interested to participate >> in >> > the Dependabot evaluation. If there is a positive feedback after the >> > initial evaluation, we could proceed with creating a JEP to define the >> flow >> > and the usage/administration policies. >> > >> > What do you think? >> > >> > Thanks in advance, >> > Oleg >> > >> > -- >> > 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 [email protected] <javascript:>. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLA1W66hN6PmaQaBUai2MJSo1nnWJA1y59tcJQskEPrMvA%40mail.gmail.com >> . >> > For more options, visit https://groups.google.com/d/optout. >> -- >> GitHub: https://github.com/rtyler >> >> GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2 >> >> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/20190221161048.2imlqsgphzjf7nnf%40grape >> . >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9ae69c40-fbc2-4e44-993c-4b22648867dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
