Re: [DISCUSS] Automated security fixes via dependabot
Creating a JIRA shouldn't be too painful making use of GitHub Actions. We should be able to trigger this whenever a dependabot PR is created. It does add an extra dependency on GitHub, but if we're using dependabot, we have that anyway. -- Michael Mior mm...@apache.org Le lun. 14 oct. 2019 à 13:36, Vladimir Sitnikov a écrit : > > I guess the missing bit is the bot that automatically creates JIRA for > Dependabot issues. > > What if we create one? > > Vladimir
Re: [DISCUSS] Automated security fixes via dependabot
I guess the missing bit is the bot that automatically creates JIRA for Dependabot issues. What if we create one? Vladimir
Re: [DISCUSS] Automated security fixes via dependabot
I've been using Dependabot on my fork of a few Apache repos (including the Calcite related ones [1][2][3]) for over a year now. I had to configure dependabot to point to these repositories. It is a nice reminder of all the different dependencies that can be updated. There is also a nice link to the changelog/release notes typically so you can find out what changed. I didn't realize that Github was going to start pushing PRs. Typically I've manually looked at the list of PRs and updated the dependencies accordingly after creating a Jira like CALCITE-2789 [4]. The PRs are a good sanity check if the change will be easy or not since the tests pass/fail based on the configured Travis jobs. After committing the change, I then go back to Github and either force dependabot to rebase the PRs or wait for dependabot to notice the update and it will autoclose the stale PRs. So I am in favor of using the automated PRs in some way at least to know what is out of date. I've seen some of the PRs do large jumps in dependency version (ie: 1.x to 2.x) so automerging probably isn't the best idea (unless there is a way to tag the PR as reviewed). I've been personally taking a monthly approach to dependencies for Apache Knox where I try to once a month update dependencies. This seems to me like a reasonable tradeoff of doing dependency updates frequently but not too frequently [5] and [6]. [1] https://github.com/risdenk/calcite/pulls [2] https://github.com/risdenk/calcite-avatica/pulls [3] https://github.com/risdenk/calcite-avatica-go/pulls [4] https://issues.apache.org/jira/browse/CALCITE-2789 [5] https://issues.apache.org/jira/browse/KNOX-2009 [6] https://issues.apache.org/jira/browse/KNOX-2049 Kevin Risden On Mon, Oct 14, 2019 at 6:40 AM Francis Chuang wrote: > +1 to squashing all these changes during a release. However, my only > concern is that if upgrading the dependencies during a release breaks > something in the codebase and turns into a larger change. I think in > this case, the change should not be squashed with the other commits and > be a standalone one. > > Francis > > On 13/10/2019 4:16 pm, Julian Hyde wrote: > > I’ve not looked at the PRs but they sound useful. Keeping software > secure these days is a moving target; we have to do work just to keep up. > All of our dependencies are doing that work too, and so we need to keep up > to date with them. > > > > I think it would be useful to have a task before each release to merge > in the ones that look important. > > > > If you are concerned that this will result in many “small” changes with > no JIRA case number, the person merging the PRs could squash them into a > single commit with its own JIRA case. (I’d use 'git cherry-pick … ; git > cherry-pick ; git rebase -i origin/master’) > > > > Julian > > > > > >> On Oct 12, 2019, at 1:01 PM, Muhammad Gelbana > wrote: > >> > >> Why would we not merge those PRs or even disable the whole thing ? > >> > >> > >> > >> On Fri, Oct 11, 2019 at 12:09 AM Francis Chuang < > francischu...@apache.org> > >> wrote: > >> > >>> Dependabot is a bot on Github that opens PRs to automatically upgrade > >>> out of date dependencies to fix security issues. Recently, Github > >>> acquired dependabot and is gradually enabling the bot on all > repositories. > >>> > >>> It just opened a PR to upgrade a few dependencies in the Avatica > >>> repository: https://github.com/apache/calcite-avatica/pull/114 > >>> > >>> I'd like to start some discussion as to how we should deal with these > >>> PRs. For some background, dependency upgrades should usually have a > jira > >>> issue number assigned, so that the change is fully trackable. We > >>> recently had some discussion regarding trivial fixes to documentation > >>> and the consensus was that changes to the code is not considered to be > >>> trivial and that an issue should be filed on jira. > >>> > >>> If we will not merge these PRs, I think it makes sense to ask infra to > >>> disable them. Having these open PRs and then closing them manually seem > >>> to generate a lot of noise. According to the documentation for > >>> dependabot [1] it appears that we can either opt out of having > >>> dependabot opening PRs completely or have it open PRs. There is no > >>> middle-ground where dependabot/Github sends members of the repo a > >>> notification for security issues, but do not open any PRs. > >>> > >>> What do you guys think? > >>> > >>> Francis > >>> > >>> [1] > >>> > https://help.github.com/en/articles/configuring-automated-security-fixes > >>> > > >
Re: [DISCUSS] Automated security fixes via dependabot
+1 to squashing all these changes during a release. However, my only concern is that if upgrading the dependencies during a release breaks something in the codebase and turns into a larger change. I think in this case, the change should not be squashed with the other commits and be a standalone one. Francis On 13/10/2019 4:16 pm, Julian Hyde wrote: I’ve not looked at the PRs but they sound useful. Keeping software secure these days is a moving target; we have to do work just to keep up. All of our dependencies are doing that work too, and so we need to keep up to date with them. I think it would be useful to have a task before each release to merge in the ones that look important. If you are concerned that this will result in many “small” changes with no JIRA case number, the person merging the PRs could squash them into a single commit with its own JIRA case. (I’d use 'git cherry-pick … ; git cherry-pick ; git rebase -i origin/master’) Julian On Oct 12, 2019, at 1:01 PM, Muhammad Gelbana wrote: Why would we not merge those PRs or even disable the whole thing ? On Fri, Oct 11, 2019 at 12:09 AM Francis Chuang wrote: Dependabot is a bot on Github that opens PRs to automatically upgrade out of date dependencies to fix security issues. Recently, Github acquired dependabot and is gradually enabling the bot on all repositories. It just opened a PR to upgrade a few dependencies in the Avatica repository: https://github.com/apache/calcite-avatica/pull/114 I'd like to start some discussion as to how we should deal with these PRs. For some background, dependency upgrades should usually have a jira issue number assigned, so that the change is fully trackable. We recently had some discussion regarding trivial fixes to documentation and the consensus was that changes to the code is not considered to be trivial and that an issue should be filed on jira. If we will not merge these PRs, I think it makes sense to ask infra to disable them. Having these open PRs and then closing them manually seem to generate a lot of noise. According to the documentation for dependabot [1] it appears that we can either opt out of having dependabot opening PRs completely or have it open PRs. There is no middle-ground where dependabot/Github sends members of the repo a notification for security issues, but do not open any PRs. What do you guys think? Francis [1] https://help.github.com/en/articles/configuring-automated-security-fixes
Re: [DISCUSS] Automated security fixes via dependabot
I’ve not looked at the PRs but they sound useful. Keeping software secure these days is a moving target; we have to do work just to keep up. All of our dependencies are doing that work too, and so we need to keep up to date with them. I think it would be useful to have a task before each release to merge in the ones that look important. If you are concerned that this will result in many “small” changes with no JIRA case number, the person merging the PRs could squash them into a single commit with its own JIRA case. (I’d use 'git cherry-pick … ; git cherry-pick ; git rebase -i origin/master’) Julian > On Oct 12, 2019, at 1:01 PM, Muhammad Gelbana wrote: > > Why would we not merge those PRs or even disable the whole thing ? > > > > On Fri, Oct 11, 2019 at 12:09 AM Francis Chuang > wrote: > >> Dependabot is a bot on Github that opens PRs to automatically upgrade >> out of date dependencies to fix security issues. Recently, Github >> acquired dependabot and is gradually enabling the bot on all repositories. >> >> It just opened a PR to upgrade a few dependencies in the Avatica >> repository: https://github.com/apache/calcite-avatica/pull/114 >> >> I'd like to start some discussion as to how we should deal with these >> PRs. For some background, dependency upgrades should usually have a jira >> issue number assigned, so that the change is fully trackable. We >> recently had some discussion regarding trivial fixes to documentation >> and the consensus was that changes to the code is not considered to be >> trivial and that an issue should be filed on jira. >> >> If we will not merge these PRs, I think it makes sense to ask infra to >> disable them. Having these open PRs and then closing them manually seem >> to generate a lot of noise. According to the documentation for >> dependabot [1] it appears that we can either opt out of having >> dependabot opening PRs completely or have it open PRs. There is no >> middle-ground where dependabot/Github sends members of the repo a >> notification for security issues, but do not open any PRs. >> >> What do you guys think? >> >> Francis >> >> [1] >> https://help.github.com/en/articles/configuring-automated-security-fixes >>
Re: [DISCUSS] Automated security fixes via dependabot
Why would we not merge those PRs or even disable the whole thing ? On Fri, Oct 11, 2019 at 12:09 AM Francis Chuang wrote: > Dependabot is a bot on Github that opens PRs to automatically upgrade > out of date dependencies to fix security issues. Recently, Github > acquired dependabot and is gradually enabling the bot on all repositories. > > It just opened a PR to upgrade a few dependencies in the Avatica > repository: https://github.com/apache/calcite-avatica/pull/114 > > I'd like to start some discussion as to how we should deal with these > PRs. For some background, dependency upgrades should usually have a jira > issue number assigned, so that the change is fully trackable. We > recently had some discussion regarding trivial fixes to documentation > and the consensus was that changes to the code is not considered to be > trivial and that an issue should be filed on jira. > > If we will not merge these PRs, I think it makes sense to ask infra to > disable them. Having these open PRs and then closing them manually seem > to generate a lot of noise. According to the documentation for > dependabot [1] it appears that we can either opt out of having > dependabot opening PRs completely or have it open PRs. There is no > middle-ground where dependabot/Github sends members of the repo a > notification for security issues, but do not open any PRs. > > What do you guys think? > > Francis > > [1] > https://help.github.com/en/articles/configuring-automated-security-fixes >
