You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@apache.org by lewis john mcgibbney <le...@apache.org> on 2021/08/29 14:38:34 UTC
Dependabot-like solution for Apache projects
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
Re: Dependabot-like solution for Apache projects
Posted by Chris Lambertus <cm...@apache.org>.
We still do not allow dependabot to write to repos. There is a way to receive the dependabot alerts via email, but no write access to the repo.
> On Aug 30, 2021, at 9:50 AM, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> I believe that changed when Github bought dependabot and it become
> "embedded" in GitHub soon after: https://dependabot.com/blog/hello-github/
>
> J.
>
>
> On Mon, Aug 30, 2021 at 3:43 PM Lewis John McGibbney <le...@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 <le...@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
>>>>
>>>
>>
Re: Re: Dependabot-like solution for Apache projects
Posted by Jarek Potiuk <ja...@potiuk.com>.
I believe that changed when Github bought dependabot and it become
"embedded" in GitHub soon after: https://dependabot.com/blog/hello-github/
J.
On Mon, Aug 30, 2021 at 3:43 PM Lewis John McGibbney <le...@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 <le...@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
> > >
> >
>
Re: Dependabot-like solution for Apache projects
Posted by David Jencks <da...@gmail.com>.
Theoretically, dependabot ought to be able to create it’s branch in a forked repo, just like any other non-committer, and create a PR from that, which can be merged by a committer. I believe this would give the same committer workflow without violating Apache policy. I have no idea if dependabot can currently do this. It would certainly create less noise in the Apache repo.
David Jencks
> On Aug 31, 2021, at 12:33 PM, Gary Gregory <ga...@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 <cm...@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 <ga...@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 <le...@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 <le...@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
>>>>>>
>>>>>
>>>>
>>
>>
Re: Dependabot-like solution for Apache projects
Posted by sebb <se...@gmail.com>.
On Fri, 3 Sept 2021 at 00:16, 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?
The ASF repo has been changed by a bot.
The bot should not be able to update the ASF repo, even if it does so
in a separate branch.
Maybe we should allow anyone to create their own branch in our repos.
So long as the code was not merged into one of our branches, would
that be a problem?
(Rhetorical question)
> On Fri, 3 Sep 2021 at 8:19 am, David Jencks <da...@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 <ga...@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 <cm...@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 <ga...@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 <le...@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 <
> > lewismc@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
Re: Dependabot-like solution for Apache projects
Posted by Ismaël Mejía <ie...@gmail.com>.
At the time I thought the issue of write permissions was more about IP
ownership of bot contributions, so I filled
https://issues.apache.org/jira/browse/LEGAL-491
From the current discussion the 'write' permissions to create the
branches seems more of a technical dependabot detail than a real issue
because the bot is not merging automatically the code into the main
repository branches and still requires supervision / approval from a
committer (which is consistent with the argument at the LEGAL ticket),
of course I understand the ASF Infra team argument because of the
security risk in case the 'bot' gets compromised + the additional
noise of having the refs there.
I wonder if github could possibly fix this. We had dependabot enabled
at some point in different projects (when it did not require the write
permissions) and it helped us easily catch and fix various security
issues. It is such a helpful tool that it is worth to have.
On Fri, Sep 3, 2021 at 6:52 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> Agree with Christopher that "technically" this does not matter if branch is
> fork PR or branch PR. And I also see the usefulness of Dependabot. I used
> it in the past and it's been extremely easy and helpful - with all the
> changelogs/release notes right in the PR you could find in exactly the
> moment and place you needed them.
>
> There is one very small difference - namely the visibility of those refs.
> When you have fork PR refs, you do not see them in the UI of GitHub outside
> of the PR, with a clear indication it comes from a fork. Whereas when you
> have PR in the repo, you see both PR and the branch in the "main" repo.
> For me it's not a problem though. I think the "3rd-party" motivation does
> not come from "visibility" but "technical feasibility of writing to the
> repo"
> But I am not sure what is the motivation behind the "3rd-party" rule, and
> what actually constitutes a 3rd-party. GitHub could very easily write a
> change to any of our repos and we probably would not notice (especially if
> you rebase and push --force often),
> We already implicitly trust GitHub and they are our "infrastructure
> provider" - we have business relationship with them, and I guess they do
> not qualify as 3rd-party because (I am guessing here) we have a legal
> agreement with them that allows to qualify them as not a "3rd-party" in
> this case.
> The ASF did not have a legal agreement with Dependabot. GitHub owns
> Dependabot and integrates them in their service. I wonder if our legal
> agreement with GitHub also covers subsidiaries (and I am not even sure -
> maybe Dependabot is just a brand after acquisition and legally they ARE
> GitHub)
>
> I think in this case both "3rd-party" and "add code to the repo" are
> defined well enough and they are open for interpretation. Who should
> interpret that ? Board? VP legal?
>
> I think it's worth considering revising the "no Dependabot" rule by the
> board. It made a lot of sense 2 years ago but I think a lot changed at the
> moment Dependabot was acquired by GitHub (so initially I even thought this
> is already a solved problem).
>
> Maybe that's a good time to review the stance taking that ownership change
> into consideration?
>
> J.
>
>
> On Fri, Sep 3, 2021 at 6:21 PM Christopher <ct...@apache.org> wrote:
>
> > 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 <se...@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 <da...@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.jencks@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.jencks@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 <
> > > garydgregory@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 <cm...@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 <
> > > > > garydgregory@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 <
> > > > > >> lewismc@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 <
> > > > > >>>> lewismc@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
> > >
> >
Re: Dependabot-like solution for Apache projects
Posted by Jarek Potiuk <ja...@potiuk.com>.
Agree with Christopher that "technically" this does not matter if branch is
fork PR or branch PR. And I also see the usefulness of Dependabot. I used
it in the past and it's been extremely easy and helpful - with all the
changelogs/release notes right in the PR you could find in exactly the
moment and place you needed them.
There is one very small difference - namely the visibility of those refs.
When you have fork PR refs, you do not see them in the UI of GitHub outside
of the PR, with a clear indication it comes from a fork. Whereas when you
have PR in the repo, you see both PR and the branch in the "main" repo.
For me it's not a problem though. I think the "3rd-party" motivation does
not come from "visibility" but "technical feasibility of writing to the
repo"
But I am not sure what is the motivation behind the "3rd-party" rule, and
what actually constitutes a 3rd-party. GitHub could very easily write a
change to any of our repos and we probably would not notice (especially if
you rebase and push --force often),
We already implicitly trust GitHub and they are our "infrastructure
provider" - we have business relationship with them, and I guess they do
not qualify as 3rd-party because (I am guessing here) we have a legal
agreement with them that allows to qualify them as not a "3rd-party" in
this case.
The ASF did not have a legal agreement with Dependabot. GitHub owns
Dependabot and integrates them in their service. I wonder if our legal
agreement with GitHub also covers subsidiaries (and I am not even sure -
maybe Dependabot is just a brand after acquisition and legally they ARE
GitHub)
I think in this case both "3rd-party" and "add code to the repo" are
defined well enough and they are open for interpretation. Who should
interpret that ? Board? VP legal?
I think it's worth considering revising the "no Dependabot" rule by the
board. It made a lot of sense 2 years ago but I think a lot changed at the
moment Dependabot was acquired by GitHub (so initially I even thought this
is already a solved problem).
Maybe that's a good time to review the stance taking that ownership change
into consideration?
J.
On Fri, Sep 3, 2021 at 6:21 PM Christopher <ct...@apache.org> wrote:
> 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 <se...@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 <da...@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.jencks@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.jencks@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 <
> > garydgregory@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 <cm...@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 <
> > > > garydgregory@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 <
> > > > >> lewismc@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 <
> > > > >>>> lewismc@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
> >
>
Re: Dependabot-like solution for Apache projects
Posted by Dave Fisher <wa...@apache.org>.
I have similar thoughts about branches and a PR.
If dependabot were allowed then a FAQ page on infra.apache.org <http://infra.apache.org/> would be useful regarding configuration and required review of the updated dependents. Such discussion would be focused on issues such as looking for license changes and assuring that no supply side security issues have occurred.
Regards,
Dave
> On Sep 3, 2021, at 9:20 AM, Christopher <ct...@apache.org> wrote:
>
> 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 <se...@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 <da...@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.jencks@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.jencks@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 <
>> garydgregory@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 <cm...@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 <
>>>> garydgregory@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 <
>>>>>> lewismc@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 <
>>>>>>>> lewismc@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
>>
Re: Dependabot-like solution for Apache projects
Posted by Christopher <ct...@apache.org>.
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 <se...@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 <da...@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.jencks@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.jencks@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 <
> garydgregory@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 <cm...@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 <
> > > garydgregory@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 <
> > > >> lewismc@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 <
> > > >>>> lewismc@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
>
Re: Dependabot-like solution for Apache projects
Posted by sebb <se...@gmail.com>.
On Fri, 3 Sept 2021 at 01:09, Olivier Lamy <ol...@apache.org> wrote:
>
> On Fri, 3 Sept 2021 at 09:57, David Jencks <da...@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 <da...@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 <da...@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 <ga...@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 <cm...@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 <
> > garydgregory@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 <
> > >> lewismc@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 <
> > >>>> lewismc@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
Re: Dependabot-like solution for Apache projects
Posted by Olivier Lamy <ol...@apache.org>.
On Fri, 3 Sept 2021 at 09:57, David Jencks <da...@gmail.com> wrote:
> I’m afraid I don’t understand your “the result is the same” argument.
>
result == Apache committer merging the bot commit
>
> 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 <da...@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 <da...@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 <ga...@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 <cm...@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 <
> garydgregory@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 <
> >> lewismc@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 <
> >>>> lewismc@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
Re: Dependabot-like solution for Apache projects
Posted by David Jencks <da...@gmail.com>.
I’m afraid I don’t understand your “the result is the same” argument.
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?
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 <da...@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 <da...@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 <ga...@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 <cm...@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 <ga...@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 <
>> lewismc@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 <
>>>> lewismc@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
Re: Dependabot-like solution for Apache projects
Posted by Olivier Lamy <ol...@apache.org>.
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 <da...@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 <da...@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 <ga...@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 <cm...@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 <ga...@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 <
> lewismc@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 <
> >> lewismc@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
Re: Dependabot-like solution for Apache projects
Posted by Chris Lambertus <cm...@apache.org>.
> On Sep 2, 2021, at 4:31 PM, David Jencks <da...@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.
Websites do not generally fall under the same types of provenance requirements that Legal has laid out, so the restrictions are not as stringent. The fact that Dependabot creates a branch -inside an ASF repo- constitutes 3rd party write access to code by a non-committer, and is in violation of the requirements of the Foundation. If Dependabot used a forked non-ASF repo to generate the PR, there would be no problem. Gaining an exception to this policy for Dependabot would require discussions starting with VP-Infra.
-Chris
ASF Infra
>
> 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 <da...@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 <ga...@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 <cm...@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 <ga...@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 <le...@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 <
>>> lewismc@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
>
Re: Dependabot-like solution for Apache projects
Posted by David Jencks <da...@gmail.com>.
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 <da...@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 <ga...@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 <cm...@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 <ga...@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 <le...@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 <
>> lewismc@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
Re: Dependabot-like solution for Apache projects
Posted by Olivier Lamy <ol...@apache.org>.
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 <da...@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 <ga...@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 <cm...@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 <ga...@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 <le...@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 <
> lewismc@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
Re: Dependabot-like solution for Apache projects
Posted by David Jencks <da...@gmail.com>.
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 <ga...@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 <cm...@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 <ga...@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 <le...@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 <lewismc@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
Re: Dependabot-like solution for Apache projects
Posted by Olivier Lamy <ol...@apache.org>.
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 <ga...@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 <cm...@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 <ga...@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 <le...@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 <lewismc@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
Re: Dependabot-like solution for Apache projects
Posted by Gary Gregory <ga...@gmail.com>.
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 <cm...@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 <ga...@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 <le...@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 <le...@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
> >>>>
> >>>
> >>
>
>
Re: Dependabot-like solution for Apache projects
Posted by Chris Lambertus <cm...@apache.org>.
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 <ga...@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 <le...@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 <le...@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
>>>>
>>>
>>
Re: Re: Dependabot-like solution for Apache projects
Posted by Gary Gregory <ga...@gmail.com>.
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 <le...@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 <le...@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
> > >
> >
>
Re: Re: Dependabot-like solution for Apache projects
Posted by Lewis John McGibbney <le...@apache.org>.
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 <le...@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
> >
>
Re: Dependabot-like solution for Apache projects
Posted by sebb <se...@gmail.com>.
On Sun, 29 Aug 2021 at 15:42, Gary Gregory <ga...@gmail.com> wrote:
>
> Most of Apache Common's components' are happy users of Dependabot, which is
> used on our GitHub mirrored repositories.
Not all the developers are happy however, as it generates lots and
lots of mail traffic, as well as extra work.
It has doubled the issues traffic, e.g.
https://lists.apache.org/list.html?issues@commons.apache.org:2018-11
https://lists.apache.org/list.html?issues@commons.apache.org:2019-11
It also affects the commit traffic.
It might be suitable for a project with few components and frequent
releases, but for Commons it means that lots of PRs can be generated
for components that are rarely updated.
Also note that it does not know if an updated dependency is usable:
e.g. if the dependency requires a more recent JVM release.
This needs checking before the PR can be applied.
A dependency may be updated several times between releases.
This all increases the amount of work.
YMMV
> Gary
>
>
> On Sun, Aug 29, 2021, 10:38 lewis john mcgibbney <le...@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
> >
Re: Dependabot-like solution for Apache projects
Posted by Gary Gregory <ga...@gmail.com>.
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 <le...@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
>