I feel like people are getting a bit hung up on the fact that dependabot creates branches in the repo directly when that isn't any different from what GitHub is doing for pull requests.
Dependabot creates refs in git under refs/heads/dependabot/* (this is customizable, to some extent by the repo owners with a config file) GitHub natively creates refs for pull requests under refs/pull/* Both write directly to the repo. Neither is a problem. The only difference is that we mirror some refs and not others by default, so we forget about the PR refs. It should be noted that dependabot's refs (called branches, only because the refs are under refs/heads/*) are trivial config changes, and not really code and definitely don't contain any IP whose provenance matters. The utility as branches rather than as non-branch refs like pull requests is to provide a writable place for the devs to add commits to resolve any actual code changes to make the version bumps function before the PR is merged. I really don't see the problem here, but if we really don't want to mirror these refs, like PR refs, we could just exclude them in the mirror process, although I think that would cause problems if devs are adding commits to these branches to resolve issues before merging. Either these branches contain trivial changes, or they contain dev additions. So either way, I don't see a problem mirroring them. But it could be done if policy disallowed it. Personally, I think it should be allowed, as the branches are not substantially different from PR refs, do not contain substantial IP unless the devs add commits, are transient, and the tool is immensely useful. Since the tool is managed by GitHub itself and not another third party, and we have a relationship with GitHub as a hosting service for mirroring our repos, I think the risk is further mitigated. We already trust GitHub to write PR refs to the repos, and to function properly as a bidirectional mirror, so why not trust them for this immensely useful tool that empowers projects to develop more secure builds? I think we shouldn't let nitpicking over policy technicalities get in the way of doing what is reasonable here. If we really don't trust these refs, just exclude them from the mirror process to the gitbox copy. But I see no reason we can't trust devs to enable this tool and decide for their own workflows. On Fri, Sep 3, 2021, 06:15 sebb <seb...@gmail.com> wrote: > On Fri, 3 Sept 2021 at 01:09, Olivier Lamy <ol...@apache.org> wrote: > > > > On Fri, 3 Sept 2021 at 09:57, David Jencks <david.a.jen...@gmail.com> > wrote: > > > > > I’m afraid I don’t understand your “the result is the same” argument. > > > > > > > result == Apache committer merging the bot commit > > > > But that is not the only change to the repo. > The repo also has a branch containing code committed by the 3rd party. > > We cannot allow 3rd parties to add code directly to our repos. > > > > > > > Let's say a company has 2 employees, Arthur, who is not an Apache > > > committer on project X, and Bernadette who is. Arthur writes some > code and > > > submits a PR to project X. In scenario 1, Bernadette merges the PR > and in > > > scenario 2 Arthur does. The result is the same!! (at least the > resulting > > > code is the same, there will be some difference in the fields in the > > > commit) So should we allow scenario 2? > > > > > > > except in our case Arthur (i.e the bot never merge his pr but only Apache > > committer merge to master/main branches) > > > > > > > > > > > > David Jencks > > > > > > > On Sep 2, 2021, at 4:42 PM, Olivier Lamy <ol...@apache.org> wrote: > > > > > > > > I perfectly understand this. > > > > But my point was at the end the result is the same! > > > > If we follow such reasoning, why do we use github as we do not > control > > > what > > > > is happening there? > > > > but yeah I'm having an already lost discussion :) > > > > > > > > On Fri, 3 Sept 2021 at 09:32, David Jencks <david.a.jen...@gmail.com > > > > > wrote: > > > > > > > >> The difference is whether a non-committer has write access to an > Apache > > > >> repo. In this case the non-committer is some code GitHub maintains > > > that we > > > >> have no control over. Why should we trust it not to modify a real > > > branch? > > > >> > > > >> To now argue on the other side of the issue, the git website > publishing > > > >> workflow using .asf.yaml allows Jenkins jobs to automatically > commit to > > > >> specific branches in Apache repos as part of publishing websites. I > > > can’t > > > >> say I’m all that clear on how the two situations differ. One > > > difference is > > > >> that the Jenkins script is set up and presumably written by an > Apache > > > >> committer: also infra restricts which branch(es) the Jenkins script > > > commits > > > >> to. > > > >> > > > >> David Jencks > > > >> > > > >>> On Sep 2, 2021, at 4:16 PM, Olivier Lamy <ol...@apache.org> wrote: > > > >>> > > > >>> So what happen here? > > > >>> If I understand correctly dependabot creates a branch in a fork > > > >> repository > > > >>> with a commit then this commit is merged back to the Apache GitHub > repo > > > >> by > > > >>> a committer. > > > >>> > > > >>> In the previous model dependabot created a branch in the Apache > GitHub > > > >> repo > > > >>> then a committer merged this back to master or any other branch. > > > >>> > > > >>> In both case there is a commit by a bot which has been merged by a > > > >>> committer.. > > > >>> > > > >>> What is exactly the difference at the end? > > > >>> > > > >>> On Fri, 3 Sep 2021 at 8:19 am, David Jencks < > david.a.jen...@gmail.com> > > > >>> wrote: > > > >>> > > > >>>> After thinking about it for a couple of minutes I’m fully behind > > > Apache > > > >>>> policy forbidding automated commits to an Apache repository. If > > > Eclipse > > > >>>> allows such commits I’d rather suspect they haven’t noticed them. > > > >>>> > > > >>>> Assuming that dependabot can’t deal with making it’s branch in a > > > >> separate > > > >>>> repo it might be possible to make something like this work: > > > >>>> > > > >>>> 1. Someone fork the apache repo. > > > >>>> 2. Use something like > > > >>>> > > > >> > > > > https://mathieu.carbou.me/post/649318432483033088/automatic-fork-syncing-with-github > > > >>>> to keep this fork up to date with the Apache repo. > > > >>>> 3. Run dependabot on this fork. > > > >>>> > > > >>>> In these circumstances I’m not sure what the target of the > dependabot > > > PR > > > >>>> would be or, if it’s the fork, how hard it would be to make a PR > to > > > the > > > >>>> Apache repo. > > > >>>> 4. Do something to apply the dependabot PR/changes to the apache > repo. > > > >>>> > > > >>>> David Jencks > > > >>>> > > > >>>>> On Sep 2, 2021, at 2:48 PM, Olivier Lamy <ol...@apache.org> > wrote: > > > >>>>> > > > >>>>> Hi, > > > >>>>> Really? This sounds like a productivity killer to remove such > > > >> feature... > > > >>>>> the bot never write to master branch it just creates a branch > and pr > > > >>>> which > > > >>>>> need to be validated/merged by a valid committer. > > > >>>>> FYI eclipse foundation definitely accepts this without problem > so I > > > >> guess > > > >>>>> we have a similar level of source management. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Wed, 1 Sept 2021 at 05:33, Gary Gregory < > garydgreg...@gmail.com> > > > >>>> wrote: > > > >>>>> > > > >>>>>> I am missing something here: the whole point of dependabot is > that > > > it > > > >>>>>> creates a branch in GitHub, runs a build, and creates a PR. If > you > > > >> like > > > >>>> the > > > >>>>>> results, you can click merge, a huge time saver. > > > >>>>>> > > > >>>>>> I really don't want to loose this killer feature. > > > >>>>>> > > > >>>>>> Gary > > > >>>>>> > > > >>>>>> On Tue, Aug 31, 2021, 11:33 Chris Lambertus <c...@apache.org> > wrote: > > > >>>>>> > > > >>>>>>> Third party write access to code repositories is expressly > > > forbidden > > > >> by > > > >>>>>>> Foundation policy: > > > >>>>>>> > > > >>>>>>> https://infra.apache.org/repository-access.html < > > > >>>>>>> https://infra.apache.org/repository-access.html> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Infra has worked with GitHub to prevent dependabot from being > able > > > to > > > >>>>>>> write to our repos, but it appears that it is still able to > under > > > >> some > > > >>>>>>> circumstances. We will open yet another support case with > GitHub > > > >>>>>> regarding > > > >>>>>>> this. > > > >>>>>>> > > > >>>>>>> Here is an example of a third party commit: > > > >>>>>>> > > > >>>>>>> https://github.com/apache/commons-io/pull/264 < > > > >>>>>>> https://github.com/apache/commons-io/pull/264> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>> > > > >> > > > > https://lists.apache.org/thread.html/ra4ca6fdfd6dd75e4579c334ca7f012df69ca00908dd48b645c1a7339%40%3Ccommits.commons.apache.org%3E > > > >>>>>>> < > > > >>>>>>> > > > >>>>>> > > > >>>> > > > >> > > > > https://lists.apache.org/thread.html/ra4ca6fdfd6dd75e4579c334ca7f012df69ca00908dd48b645c1a7339@%3Ccommits.commons.apache.org%3E > > > >>>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> This write access to commons-io appears to be in violation of > the > > > >>>>>>> aforementioned policy. > > > >>>>>>> > > > >>>>>>> Dependabot's email alerts are currently the only acceptable > method > > > >> for > > > >>>>>>> working with the tool. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> -Chris > > > >>>>>>> ASF Infra > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>> On Aug 30, 2021, at 10:53 AM, Gary Gregory < > > > garydgreg...@gmail.com> > > > >>>>>>> wrote: > > > >>>>>>>> > > > >>>>>>>> The Apache git repo must be mirrored from Apache to GitHub, > for > > > >>>> example > > > >>>>>>>> https://github.com/apache/commons-io, then you add a .github > > > folder > > > >>>>>> and > > > >>>>>>>> files (see above link). > > > >>>>>>>> > > > >>>>>>>> Gary > > > >>>>>>>> > > > >>>>>>>> On Mon, Aug 30, 2021, 09:43 Lewis John McGibbney < > > > >> lewi...@apache.org> > > > >>>>>>> wrote: > > > >>>>>>>> > > > >>>>>>>>> Thanks Gary and Sebb. > > > >>>>>>>>> How do I turn dependabot on? Last time I tried I was informed > > > that > > > >>>> due > > > >>>>>>> to > > > >>>>>>>>> the program requiring write permissions to the repository, it > > > >> wasn’t > > > >>>>>>>>> possible… > > > >>>>>>>>> This policy must have changed… > > > >>>>>>>>> Thanks for any info. > > > >>>>>>>>> lewismc > > > >>>>>>>>> > > > >>>>>>>>> On 2021/08/29 14:42:00 Gary Gregory wrote: > > > >>>>>>>>>> Most of Apache Common's components' are happy users of > > > Dependabot, > > > >>>>>>> which > > > >>>>>>>>> is > > > >>>>>>>>>> used on our GitHub mirrored repositories. > > > >>>>>>>>>> > > > >>>>>>>>>> Gary > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> On Sun, Aug 29, 2021, 10:38 lewis john mcgibbney < > > > >>>> lewi...@apache.org > > > >>>>>>> > > > >>>>>>>>> wrote: > > > >>>>>>>>>> > > > >>>>>>>>>>> Hi builds@, > > > >>>>>>>>>>> I was advised to ask my question here instead of > > > >> general@incubator. > > > >>>>>>>>>>> Thanks for any feedback > > > >>>>>>>>>>> > > > >>>>>>>>>>>> I understand that we cannot use automated tooling, > > > specifically > > > >>>>>>>>> Dependbot > > > >>>>>>>>>>> ( > > > >>>>>>>>>>>> https://dependabot.com/) because it requests write > access to > > > >> the > > > >>>>>> ASF > > > >>>>>>>>>>>> project source code. > > > >>>>>>>>>>>> I have found this functionality to be really useful and > > > wondered > > > >>>> if > > > >>>>>>>>> there > > > >>>>>>>>>>>> are any suggestions out there for automating the > dependency > > > >>>>>>>>> management > > > >>>>>>>>>>>> workflow? > > > >>>>>>>>>>>> Thanks for any feedback. > > > >>>>>>>>>>>> lewismc > > > >>>>>>>>>>> -- > > > >>>>>>>>>>> http://home.apache.org/~lewismc/ > > > >>>>>>>>>>> http://people.apache.org/keys/committer/lewismc > > > >>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>>> -- > > > >>>>> Olivier Lamy > > > >>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy > > > >>>> > > > >>>> -- > > > >>> Olivier Lamy > > > >>> http://twitter.com/olamy | http://linkedin.com/in/olamy > > > >> > > > >> > > > > > > > > -- > > > > Olivier Lamy > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > > > > > > > -- > > Olivier Lamy > > http://twitter.com/olamy | http://linkedin.com/in/olamy >
