You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@opendal.apache.org by tison <wa...@gmail.com> on 2023/06/29 14:21:30 UTC
[REQUEST] Grant permission to deploy Maven project via GitHub Actions
Hi security team members,
I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
I already verify that GitHub Actions work well for automatically deploying
OpenDAL Java binding[2].
When integrating it with upstream (apache/incuabtor-opendal), I met a
problem that deploying Maven projects requires NEXUS credentials. For my
personal repo, I can config my Apache ID and password as secrets. For
apache repos, it requires handing over the credentials to INFRA team
member. Even I can trust the member, it's a bit less than awesome.
Fortunately, INFRA provides two org-wise secrets NEXUS_USER and NEXUS_PW
for doing so[3]. But it's limited to deploying snapshots only. INFRA member
suggested me to consult security team for approval for such automatic
deployment and they would help to grant related permissions if approved.
Please help review the request to support ASF projects deploying Maven
project via GitHub Actions.
Best,
tison.
[1] http://github.com/apache/incubator-opendal
[2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
[3]
https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by Daniel Gruno <hu...@apache.org>.
On 2023-07-03 12:52, PJ Fanning wrote:
> Adding the Incubator general list.
>
> My view would be that non-snapshot binary artifacts should be signed
> with a personal signing key - ideally the signing key that was used to
> release the related source release. Unfortunately, this would mean
> adding a user's signing key to the Apache GitHub account as a secret
> so that the automated GitHub Action job could access it. I don't see
> how we could allow personal signing keys to be added like this.
We don't and won't put personal keys into any CI system.
Please see
https://infra.apache.org/release-signing.html#automated-release-signing
for how to go about this. There is a standardized workflow here.
>
> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
>>
>> cc security
>>
>> Missed in the first place.
>>
>> Best,
>> tison.
>>
>>
>> tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
>>>
>>> Hi security team members,
>>>
>>> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
>>>
>>> I already verify that GitHub Actions work well for automatically deploying OpenDAL Java binding[2].
>>>
>>> When integrating it with upstream (apache/incuabtor-opendal), I met a problem that deploying Maven projects requires NEXUS credentials. For my personal repo, I can config my Apache ID and password as secrets. For apache repos, it requires handing over the credentials to INFRA team member. Even I can trust the member, it's a bit less than awesome.
>>>
>>> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only. INFRA member suggested me to consult security team for approval for such automatic deployment and they would help to grant related permissions if approved.
>>>
>>> Please help review the request to support ASF projects deploying Maven project via GitHub Actions.
>>>
>>> Best,
>>> tison.
>>>
>>> [1] http://github.com/apache/incubator-opendal
>>> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
>>> [3] https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by PJ Fanning <fa...@gmail.com>.
One of my Pekko colleagues found that this process is documented. I
wasn't aware that this approach has been approved as long as the
security team signs off.
https://infra.apache.org/release-signing.html#automated-release-signing
On Mon, 3 Jul 2023 at 12:04, tison <wa...@gmail.com> wrote:
>
> Update mailing list. Or if I should start a new thread totally?
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年7月3日周一 19:00写道：
>
> > Hi Daniel,
> >
> > Thanks for your information! That can be an alternative for the signing
> > key.
> >
> > Right now the blocker I met is 403 from the Nexus server which I suspect
> > is the lack of permissions from the Nexus credentials. Could you confirm or
> > correct it?
> >
> > Best,
> > tison.
> >
> >
> > tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
> >
> >> Hi PJ,
> >>
> >> Thanks for sharing your thoughts!
> >>
> >> For signing key, it's a resolved topic from my perspective. I use -
> >>
> >> 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
> >> 2. Load the key from our 1password service, while since it's a specific
> >> key, I feel comfortable to pass it to INFRA member and configure as a
> >> secret alternatively.
> >>
> >> Best,
> >> tison.
> >>
> >> [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
> >>
> >>
> >> PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
> >>
> >>> Adding the Incubator general list.
> >>>
> >>> My view would be that non-snapshot binary artifacts should be signed
> >>> with a personal signing key - ideally the signing key that was used to
> >>> release the related source release. Unfortunately, this would mean
> >>> adding a user's signing key to the Apache GitHub account as a secret
> >>> so that the automated GitHub Action job could access it. I don't see
> >>> how we could allow personal signing keys to be added like this.
> >>>
> >>> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
> >>> >
> >>> > cc security
> >>> >
> >>> > Missed in the first place.
> >>> >
> >>> > Best,
> >>> > tison.
> >>> >
> >>> >
> >>> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> >>> >>
> >>> >> Hi security team members,
> >>> >>
> >>> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
> >>> >>
> >>> >> I already verify that GitHub Actions work well for automatically
> >>> deploying OpenDAL Java binding[2].
> >>> >>
> >>> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
> >>> problem that deploying Maven projects requires NEXUS credentials. For my
> >>> personal repo, I can config my Apache ID and password as secrets. For
> >>> apache repos, it requires handing over the credentials to INFRA team
> >>> member. Even I can trust the member, it's a bit less than awesome.
> >>> >>
> >>> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
> >>> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
> >>> INFRA member suggested me to consult security team for approval for such
> >>> automatic deployment and they would help to grant related permissions if
> >>> approved.
> >>> >>
> >>> >> Please help review the request to support ASF projects deploying
> >>> Maven project via GitHub Actions.
> >>> >>
> >>> >> Best,
> >>> >> tison.
> >>> >>
> >>> >> [1] http://github.com/apache/incubator-opendal
> >>> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> >>> >> [3]
> >>> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> >>> >>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by PJ Fanning <fa...@gmail.com>.
One of my Pekko colleagues found that this process is documented. I
wasn't aware that this approach has been approved as long as the
security team signs off.
https://infra.apache.org/release-signing.html#automated-release-signing
On Mon, 3 Jul 2023 at 12:04, tison <wa...@gmail.com> wrote:
>
> Update mailing list. Or if I should start a new thread totally?
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年7月3日周一 19:00写道：
>
> > Hi Daniel,
> >
> > Thanks for your information! That can be an alternative for the signing
> > key.
> >
> > Right now the blocker I met is 403 from the Nexus server which I suspect
> > is the lack of permissions from the Nexus credentials. Could you confirm or
> > correct it?
> >
> > Best,
> > tison.
> >
> >
> > tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
> >
> >> Hi PJ,
> >>
> >> Thanks for sharing your thoughts!
> >>
> >> For signing key, it's a resolved topic from my perspective. I use -
> >>
> >> 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
> >> 2. Load the key from our 1password service, while since it's a specific
> >> key, I feel comfortable to pass it to INFRA member and configure as a
> >> secret alternatively.
> >>
> >> Best,
> >> tison.
> >>
> >> [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
> >>
> >>
> >> PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
> >>
> >>> Adding the Incubator general list.
> >>>
> >>> My view would be that non-snapshot binary artifacts should be signed
> >>> with a personal signing key - ideally the signing key that was used to
> >>> release the related source release. Unfortunately, this would mean
> >>> adding a user's signing key to the Apache GitHub account as a secret
> >>> so that the automated GitHub Action job could access it. I don't see
> >>> how we could allow personal signing keys to be added like this.
> >>>
> >>> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
> >>> >
> >>> > cc security
> >>> >
> >>> > Missed in the first place.
> >>> >
> >>> > Best,
> >>> > tison.
> >>> >
> >>> >
> >>> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> >>> >>
> >>> >> Hi security team members,
> >>> >>
> >>> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
> >>> >>
> >>> >> I already verify that GitHub Actions work well for automatically
> >>> deploying OpenDAL Java binding[2].
> >>> >>
> >>> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
> >>> problem that deploying Maven projects requires NEXUS credentials. For my
> >>> personal repo, I can config my Apache ID and password as secrets. For
> >>> apache repos, it requires handing over the credentials to INFRA team
> >>> member. Even I can trust the member, it's a bit less than awesome.
> >>> >>
> >>> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
> >>> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
> >>> INFRA member suggested me to consult security team for approval for such
> >>> automatic deployment and they would help to grant related permissions if
> >>> approved.
> >>> >>
> >>> >> Please help review the request to support ASF projects deploying
> >>> Maven project via GitHub Actions.
> >>> >>
> >>> >> Best,
> >>> >> tison.
> >>> >>
> >>> >> [1] http://github.com/apache/incubator-opendal
> >>> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> >>> >> [3]
> >>> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> >>> >>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by PJ Fanning <fa...@gmail.com>.
One of my Pekko colleagues found that this process is documented. I
wasn't aware that this approach has been approved as long as the
security team signs off.
https://infra.apache.org/release-signing.html#automated-release-signing
On Mon, 3 Jul 2023 at 12:04, tison <wa...@gmail.com> wrote:
>
> Update mailing list. Or if I should start a new thread totally?
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年7月3日周一 19:00写道：
>
> > Hi Daniel,
> >
> > Thanks for your information! That can be an alternative for the signing
> > key.
> >
> > Right now the blocker I met is 403 from the Nexus server which I suspect
> > is the lack of permissions from the Nexus credentials. Could you confirm or
> > correct it?
> >
> > Best,
> > tison.
> >
> >
> > tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
> >
> >> Hi PJ,
> >>
> >> Thanks for sharing your thoughts!
> >>
> >> For signing key, it's a resolved topic from my perspective. I use -
> >>
> >> 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
> >> 2. Load the key from our 1password service, while since it's a specific
> >> key, I feel comfortable to pass it to INFRA member and configure as a
> >> secret alternatively.
> >>
> >> Best,
> >> tison.
> >>
> >> [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
> >>
> >>
> >> PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
> >>
> >>> Adding the Incubator general list.
> >>>
> >>> My view would be that non-snapshot binary artifacts should be signed
> >>> with a personal signing key - ideally the signing key that was used to
> >>> release the related source release. Unfortunately, this would mean
> >>> adding a user's signing key to the Apache GitHub account as a secret
> >>> so that the automated GitHub Action job could access it. I don't see
> >>> how we could allow personal signing keys to be added like this.
> >>>
> >>> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
> >>> >
> >>> > cc security
> >>> >
> >>> > Missed in the first place.
> >>> >
> >>> > Best,
> >>> > tison.
> >>> >
> >>> >
> >>> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> >>> >>
> >>> >> Hi security team members,
> >>> >>
> >>> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
> >>> >>
> >>> >> I already verify that GitHub Actions work well for automatically
> >>> deploying OpenDAL Java binding[2].
> >>> >>
> >>> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
> >>> problem that deploying Maven projects requires NEXUS credentials. For my
> >>> personal repo, I can config my Apache ID and password as secrets. For
> >>> apache repos, it requires handing over the credentials to INFRA team
> >>> member. Even I can trust the member, it's a bit less than awesome.
> >>> >>
> >>> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
> >>> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
> >>> INFRA member suggested me to consult security team for approval for such
> >>> automatic deployment and they would help to grant related permissions if
> >>> approved.
> >>> >>
> >>> >> Please help review the request to support ASF projects deploying
> >>> Maven project via GitHub Actions.
> >>> >>
> >>> >> Best,
> >>> >> tison.
> >>> >>
> >>> >> [1] http://github.com/apache/incubator-opendal
> >>> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> >>> >> [3]
> >>> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> >>> >>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Update mailing list. Or if I should start a new thread totally?
Best,
tison.
tison <wa...@gmail.com> 于2023年7月3日周一 19:00写道：
> Hi Daniel,
>
> Thanks for your information! That can be an alternative for the signing
> key.
>
> Right now the blocker I met is 403 from the Nexus server which I suspect
> is the lack of permissions from the Nexus credentials. Could you confirm or
> correct it?
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
>
>> Hi PJ,
>>
>> Thanks for sharing your thoughts!
>>
>> For signing key, it's a resolved topic from my perspective. I use -
>>
>> 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
>> 2. Load the key from our 1password service, while since it's a specific
>> key, I feel comfortable to pass it to INFRA member and configure as a
>> secret alternatively.
>>
>> Best,
>> tison.
>>
>> [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
>>
>>
>> PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
>>
>>> Adding the Incubator general list.
>>>
>>> My view would be that non-snapshot binary artifacts should be signed
>>> with a personal signing key - ideally the signing key that was used to
>>> release the related source release. Unfortunately, this would mean
>>> adding a user's signing key to the Apache GitHub account as a secret
>>> so that the automated GitHub Action job could access it. I don't see
>>> how we could allow personal signing keys to be added like this.
>>>
>>> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
>>> >
>>> > cc security
>>> >
>>> > Missed in the first place.
>>> >
>>> > Best,
>>> > tison.
>>> >
>>> >
>>> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
>>> >>
>>> >> Hi security team members,
>>> >>
>>> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
>>> >>
>>> >> I already verify that GitHub Actions work well for automatically
>>> deploying OpenDAL Java binding[2].
>>> >>
>>> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
>>> problem that deploying Maven projects requires NEXUS credentials. For my
>>> personal repo, I can config my Apache ID and password as secrets. For
>>> apache repos, it requires handing over the credentials to INFRA team
>>> member. Even I can trust the member, it's a bit less than awesome.
>>> >>
>>> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
>>> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
>>> INFRA member suggested me to consult security team for approval for such
>>> automatic deployment and they would help to grant related permissions if
>>> approved.
>>> >>
>>> >> Please help review the request to support ASF projects deploying
>>> Maven project via GitHub Actions.
>>> >>
>>> >> Best,
>>> >> tison.
>>> >>
>>> >> [1] http://github.com/apache/incubator-opendal
>>> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
>>> >> [3]
>>> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by Vladimir Sitnikov <si...@gmail.com>.
> n this way, the automation would be triggered
>at the formal tag pushed
>after the vote passed.
Correct me if I am wrong, however, if a release vote includes only sources,
then creating and publishing binaries separately would violate the release
policy.
Creating the binaries and publishing them would produce a separate release,
and the ASF release policy requires that every release should have source
package.
Vladimir
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Thank Chris for your feedback!
You're right and an alternative is to postpone the binaries release until
the vote passed, while the vote still focuses on sources and any users can
build their binaries to verify.
In this way, the automation would be triggered at the formal tag pushed
after the vote passed.
I regard either way as valid, and here we don't face a technical blocker
but try to work out a public consensus on policy to follow - any policy
should be for users' good to obtain all the well-produced binaries.
Best,
tison.
Christofer Dutz <ch...@c-ware.de> 于2023年7月4日周二 20:13写道：
> Hi Tison,
>
> well with most projects that use Maven as distribution chanel, the RC
> artifacts are in a staging repo in Nexus. If the vote fails, then this repo
> is dropped and nothing is released to the outside world. If it passes, we
> click on "release" and the artifacts are released to the outside world.
>
> And just because some projects do something in a certain way, doesn't
> always imply that this is the right way to do things.
>
> I personally have come across several Apache projects, that are not doing
> things according to Apache policies and that need to change some parts of
> what they are doing.
>
> But as I mentioned, currently we're internally discussing how to deal with
> binary releases for various reasons ... because till now officially we only
> have source releases and convenience binaries.
>
>
> Chris
>
>
>
> Am 04.07.23, 13:55 schrieb "tison" <wander4096@gmail.com <mailto:
> wander4096@gmail.com>>:
>
>
> > if It's ok to still publish RCs without a vote
>
>
> I think we vote for RCs so we always provide RCs without a vote. At least
> it's what I'm experiencing among Flink, Pulsar, and so on.
>
>
> Best,
> tison.
>
>
>
>
> Christofer Dutz <christofer.dutz@c-ware.de <mailto:
> christofer.dutz@c-ware.de>> 于2023年7月4日周二 19:52写道：
>
>
> > Hi Tison,
> >
> > Well, it definitely is better than without, however I am still not sure,
> > if It's ok to still publish RCs without a vote.
> > Currently there's quite a bit of discussion on the matter of releasing
> > binary artifacts, so I would call this part a bit in flux right now.
> >
> > But hopefully someone else will be able to provide more information on
> > this.
> >
> > Chris
> >
> >
> >
> > Am 04.07.23, 13:48 schrieb "tison" <wander4096@gmail.com <mailto:
> wander4096@gmail.com> <mailto:
> > wander4096@gmail.com <ma...@gmail.com>>>:
> >
> >
> > Hi Chris.
> >
> >
> > 1. Is -rc suffix a satisfied alternative to you?
> > 2. This can be part of binary release topics. I read our policy to
> release
> > sources only so I don't push an alert for doing so. But I do assume -rc
> > suffix could be an improvement before the podling getting graduated.
> >
> >
> > Best,
> > tison.
> >
> >
> >
> >
> > Christofer Dutz <christofer.dutz@c-ware.de <mailto:
> christofer.dutz@c-ware.de> <mailto:
> > christofer.dutz@c-ware.de <ma...@c-ware.de>>>
> 于2023年7月4日周二 19:45写道：
> >
> >
> > > Hi all,
> > >
> > > I don't think this procedure is ok according to our policies.
> > >
> > > Simply not listing a release on the project page will not help anyone
> > > using this as a dependency.
> > >
> > > At least, every time I update a dependency, I never check the projects
> > > page, if this is even a released version.
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 04.07.23, 13:37 schrieb "tison" <wander4096@gmail.com <mailto:
> wander4096@gmail.com> <mailto:
> > wander4096@gmail.com <ma...@gmail.com>> <mailto:
> > > wander4096@gmail.com <ma...@gmail.com> <mailto:
> wander4096@gmail.com <ma...@gmail.com>>>>:
> > >
> > >
> > > Here are four workflows to release Rust, Node.js, Python and Ruby
> > libraries
> > > to their conventional repository.
> > >
> > >
> > > 1. Rust Cargo -
> > >
> > >
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> >
> > >
> > > <
> > >
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> >
> > >
> > > >
> > > 2. Python PyPi -
> > >
> > >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> >
> > >
> > > <
> > >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> >
> > >
> > > >
> > > 3. Ruby Gems -
> > >
> > >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> >
> > >
> > > <
> > >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> >
> > >
> > > >
> > > 4. Node.js npm -
> > >
> > >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> >
> > >
> > > <
> > >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> >
> > >
> > > >
> > >
> > >
> > > All of them, different from the Apache Maven Nexus repository, are
> > > maintained by third-party platforms. So we request a token and share it
> > > among the Podling PMC via 1Password (a free team provision provided by
> > the
> > > team[1]).
> > >
> > >
> > > > revoked
> > >
> > >
> > > For the source releases, if the vote failed, it won't be copied to the
> > > release svn directory.
> > >
> > >
> > > For the binary releases, although all of these platforms should support
> > -rc
> > > in version tag, we release an X.Y.Z for each candidate and leave it
> there
> > > if vote failed. The version won't be listed at the official page[2].
> > >
> > >
> > > I ever advice the PPMC that using a -rc suffix would be better but they
> > use
> > > this way now for convenient development. As you can see, the version
> > number
> > > is 0.X so users should already use it at their risk. If it's
> requested, I
> > > believe the PPMC would be glad to add a notice for which ones are
> Apache
> > > voted releases or use a different version tag strategy to distinguish
> > that.
> > > There should not be any blocker technically.
> > >
> > >
> > > OpenDAL has a release document[3] that you can refer to and do not
> > hesitate
> > > to open an issue if you find anything is unclear or unexpected.
> > >
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > [1] https://github.com/1Password/1password-teams-open-source/pull/742
> <https://github.com/1Password/1password-teams-open-source/pull/742> <
> > https://github.com/1Password/1password-teams-open-source/pull/742> <
> https://github.com/1Password/1password-teams-open-source/pull/742>> <
> > > https://github.com/1Password/1password-teams-open-source/pull/742> <
> https://github.com/1Password/1password-teams-open-source/pull/742>> <
> > https://github.com/1Password/1password-teams-open-source/pull/742>> <
> https://github.com/1Password/1password-teams-open-source/pull/742&gt;>
> ;>
> > > [2] https://opendal.apache.org/download <
> https://opendal.apache.org/download> <
> > https://opendal.apache.org/download> <
> https://opendal.apache.org/download>> <
> > > https://opendal.apache.org/download> <
> https://opendal.apache.org/download>> <
> > https://opendal.apache.org/download>> <
> https://opendal.apache.org/download&gt;>>
> > > [3] https://opendal.apache.org/docs/contributing/release <
> https://opendal.apache.org/docs/contributing/release> <
> > https://opendal.apache.org/docs/contributing/release> <
> https://opendal.apache.org/docs/contributing/release>> <
> > > https://opendal.apache.org/docs/contributing/release> <
> https://opendal.apache.org/docs/contributing/release>> <
> > https://opendal.apache.org/docs/contributing/release>> <
> https://opendal.apache.org/docs/contributing/release&gt;>>
> > >
> > >
> > >
> > >
> > >
> > >
> > > PJ Fanning <fanningpj@gmail.com <ma...@gmail.com> <mailto:
> fanningpj@gmail.com <ma...@gmail.com>> <mailto:
> > fanningpj@gmail.com <ma...@gmail.com> <mailto:
> fanningpj@gmail.com <ma...@gmail.com>>>>
> > > 于2023年7月4日周二 19:17写道：
> > >
> > >
> > > > Hi Tison,
> > > >
> > > > Would it be possible to provide us with links to documentation about
> > > > how you deploy your binary artifacts and how they can be revoked if a
> > > > vote fails?
> > > >
> > > > I think this is useful for IPMC members when they are reviewing your
> > > > release candidates. It's nice to review the binaries as well as the
> > > > source artifacts, even if the source artifacts are the main point of
> > > > the vote.
> > > >
> > > > When staging RCs for review, I tend to use
> > > > * dist.apache.org (this is where the source artifacts go anyway)
> > > > * repository.apache.org (jars)
> > > >
> > > > Files on dist.apache.org can be deleted when votes fail.
> > > > With repository.apache.org, the release is a 2 phase process. You
> > > > first push to 'staging' and then you can use its Nexus UI to drop or
> > > > release the staged artifacts after the vote.
> > > >
> > > > OpenDAL is mainly in Rust but you also have a large number of
> language
> > > > bindings (see libraries list [1]), existing and planned. So
> > > > presumably, you are using a large number of different packaging tools
> > > > for your binary releases. Many of us in the IPMC would not be
> familiar
> > > > with all these packaging tools.
> > > >
> > > > You may already have documentation and if so, could you share a link?
> > > >
> > > > If there is no shareable documentation, would you be able to tell us
> > > > which Crate Registry do you use for your RC Rust binaries? Do we have
> > > > a custom registry that allows us to remove the binaries for releases
> > > > that fail?
> > > >
> > > > Any information would be appreciated.
> > > >
> > > > Regards,
> > > > PJ
> > > >
> > > > [1] https://github.com/apache/incubator-opendal <
> https://github.com/apache/incubator-opendal> <
> > https://github.com/apache/incubator-opendal> <
> https://github.com/apache/incubator-opendal>> <
> > > https://github.com/apache/incubator-opendal> <
> https://github.com/apache/incubator-opendal>> <
> > https://github.com/apache/incubator-opendal>> <
> https://github.com/apache/incubator-opendal&gt;>>
> > > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <ma...@incubator.apache.org>
> > <mailto:general-unsubscribe@incubator.apache.org <mailto:
> general-unsubscribe@incubator.apache.org>>
> > > For additional commands, e-mail: general-help@incubator.apache.org
> <ma...@incubator.apache.org>
> > <mailto:general-help@incubator.apache.org <mailto:
> general-help@incubator.apache.org>>
> > >
> >
> >
> >
> >
>
>
>
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Tison,
well with most projects that use Maven as distribution chanel, the RC artifacts are in a staging repo in Nexus. If the vote fails, then this repo is dropped and nothing is released to the outside world. If it passes, we click on "release" and the artifacts are released to the outside world.
And just because some projects do something in a certain way, doesn't always imply that this is the right way to do things.
I personally have come across several Apache projects, that are not doing things according to Apache policies and that need to change some parts of what they are doing.
But as I mentioned, currently we're internally discussing how to deal with binary releases for various reasons ... because till now officially we only have source releases and convenience binaries.
Chris
Am 04.07.23, 13:55 schrieb "tison" <wander4096@gmail.com <ma...@gmail.com>>:
> if It's ok to still publish RCs without a vote
I think we vote for RCs so we always provide RCs without a vote. At least
it's what I'm experiencing among Flink, Pulsar, and so on.
Best,
tison.
Christofer Dutz <christofer.dutz@c-ware.de <ma...@c-ware.de>> 于2023年7月4日周二 19:52写道：
> Hi Tison,
>
> Well, it definitely is better than without, however I am still not sure,
> if It's ok to still publish RCs without a vote.
> Currently there's quite a bit of discussion on the matter of releasing
> binary artifacts, so I would call this part a bit in flux right now.
>
> But hopefully someone else will be able to provide more information on
> this.
>
> Chris
>
>
>
> Am 04.07.23, 13:48 schrieb "tison" <wander4096@gmail.com <ma...@gmail.com> <mailto:
> wander4096@gmail.com <ma...@gmail.com>>>:
>
>
> Hi Chris.
>
>
> 1. Is -rc suffix a satisfied alternative to you?
> 2. This can be part of binary release topics. I read our policy to release
> sources only so I don't push an alert for doing so. But I do assume -rc
> suffix could be an improvement before the podling getting graduated.
>
>
> Best,
> tison.
>
>
>
>
> Christofer Dutz <christofer.dutz@c-ware.de <ma...@c-ware.de> <mailto:
> christofer.dutz@c-ware.de <ma...@c-ware.de>>> 于2023年7月4日周二 19:45写道：
>
>
> > Hi all,
> >
> > I don't think this procedure is ok according to our policies.
> >
> > Simply not listing a release on the project page will not help anyone
> > using this as a dependency.
> >
> > At least, every time I update a dependency, I never check the projects
> > page, if this is even a released version.
> >
> > Chris
> >
> >
> >
> > Am 04.07.23, 13:37 schrieb "tison" <wander4096@gmail.com <ma...@gmail.com> <mailto:
> wander4096@gmail.com <ma...@gmail.com>> <mailto:
> > wander4096@gmail.com <ma...@gmail.com> <mailto:wander4096@gmail.com <ma...@gmail.com>>>>:
> >
> >
> > Here are four workflows to release Rust, Node.js, Python and Ruby
> libraries
> > to their conventional repository.
> >
> >
> > 1. Rust Cargo -
> >
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> >
> > >
> > 2. Python PyPi -
> >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> >
> > >
> > 3. Ruby Gems -
> >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml>
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml>
> >
> > >
> > 4. Node.js npm -
> >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml>
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml>
> >
> > >
> >
> >
> > All of them, different from the Apache Maven Nexus repository, are
> > maintained by third-party platforms. So we request a token and share it
> > among the Podling PMC via 1Password (a free team provision provided by
> the
> > team[1]).
> >
> >
> > > revoked
> >
> >
> > For the source releases, if the vote failed, it won't be copied to the
> > release svn directory.
> >
> >
> > For the binary releases, although all of these platforms should support
> -rc
> > in version tag, we release an X.Y.Z for each candidate and leave it there
> > if vote failed. The version won't be listed at the official page[2].
> >
> >
> > I ever advice the PPMC that using a -rc suffix would be better but they
> use
> > this way now for convenient development. As you can see, the version
> number
> > is 0.X so users should already use it at their risk. If it's requested, I
> > believe the PPMC would be glad to add a notice for which ones are Apache
> > voted releases or use a different version tag strategy to distinguish
> that.
> > There should not be any blocker technically.
> >
> >
> > OpenDAL has a release document[3] that you can refer to and do not
> hesitate
> > to open an issue if you find anything is unclear or unexpected.
> >
> >
> > Best,
> > tison.
> >
> >
> > [1] https://github.com/1Password/1password-teams-open-source/pull/742 <https://github.com/1Password/1password-teams-open-source/pull/742> <
> https://github.com/1Password/1password-teams-open-source/pull/742> <https://github.com/1Password/1password-teams-open-source/pull/742>> <
> > https://github.com/1Password/1password-teams-open-source/pull/742> <https://github.com/1Password/1password-teams-open-source/pull/742>> <
> https://github.com/1Password/1password-teams-open-source/pull/742>> <https://github.com/1Password/1password-teams-open-source/pull/742&gt;>>
> > [2] https://opendal.apache.org/download <https://opendal.apache.org/download> <
> https://opendal.apache.org/download> <https://opendal.apache.org/download>> <
> > https://opendal.apache.org/download> <https://opendal.apache.org/download>> <
> https://opendal.apache.org/download>> <https://opendal.apache.org/download&gt;>>
> > [3] https://opendal.apache.org/docs/contributing/release <https://opendal.apache.org/docs/contributing/release> <
> https://opendal.apache.org/docs/contributing/release> <https://opendal.apache.org/docs/contributing/release>> <
> > https://opendal.apache.org/docs/contributing/release> <https://opendal.apache.org/docs/contributing/release>> <
> https://opendal.apache.org/docs/contributing/release>> <https://opendal.apache.org/docs/contributing/release&gt;>>
> >
> >
> >
> >
> >
> >
> > PJ Fanning <fanningpj@gmail.com <ma...@gmail.com> <mailto:fanningpj@gmail.com <ma...@gmail.com>> <mailto:
> fanningpj@gmail.com <ma...@gmail.com> <mailto:fanningpj@gmail.com <ma...@gmail.com>>>>
> > 于2023年7月4日周二 19:17写道：
> >
> >
> > > Hi Tison,
> > >
> > > Would it be possible to provide us with links to documentation about
> > > how you deploy your binary artifacts and how they can be revoked if a
> > > vote fails?
> > >
> > > I think this is useful for IPMC members when they are reviewing your
> > > release candidates. It's nice to review the binaries as well as the
> > > source artifacts, even if the source artifacts are the main point of
> > > the vote.
> > >
> > > When staging RCs for review, I tend to use
> > > * dist.apache.org (this is where the source artifacts go anyway)
> > > * repository.apache.org (jars)
> > >
> > > Files on dist.apache.org can be deleted when votes fail.
> > > With repository.apache.org, the release is a 2 phase process. You
> > > first push to 'staging' and then you can use its Nexus UI to drop or
> > > release the staged artifacts after the vote.
> > >
> > > OpenDAL is mainly in Rust but you also have a large number of language
> > > bindings (see libraries list [1]), existing and planned. So
> > > presumably, you are using a large number of different packaging tools
> > > for your binary releases. Many of us in the IPMC would not be familiar
> > > with all these packaging tools.
> > >
> > > You may already have documentation and if so, could you share a link?
> > >
> > > If there is no shareable documentation, would you be able to tell us
> > > which Crate Registry do you use for your RC Rust binaries? Do we have
> > > a custom registry that allows us to remove the binaries for releases
> > > that fail?
> > >
> > > Any information would be appreciated.
> > >
> > > Regards,
> > > PJ
> > >
> > > [1] https://github.com/apache/incubator-opendal <https://github.com/apache/incubator-opendal> <
> https://github.com/apache/incubator-opendal> <https://github.com/apache/incubator-opendal>> <
> > https://github.com/apache/incubator-opendal> <https://github.com/apache/incubator-opendal>> <
> https://github.com/apache/incubator-opendal>> <https://github.com/apache/incubator-opendal&gt;>>
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
> <mailto:general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>>
> > For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
> <mailto:general-help@incubator.apache.org <ma...@incubator.apache.org>>
> >
>
>
>
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
> if It's ok to still publish RCs without a vote
I think we vote for RCs so we always provide RCs without a vote. At least
it's what I'm experiencing among Flink, Pulsar, and so on.
Best,
tison.
Christofer Dutz <ch...@c-ware.de> 于2023年7月4日周二 19:52写道：
> Hi Tison,
>
> Well, it definitely is better than without, however I am still not sure,
> if It's ok to still publish RCs without a vote.
> Currently there's quite a bit of discussion on the matter of releasing
> binary artifacts, so I would call this part a bit in flux right now.
>
> But hopefully someone else will be able to provide more information on
> this.
>
> Chris
>
>
>
> Am 04.07.23, 13:48 schrieb "tison" <wander4096@gmail.com <mailto:
> wander4096@gmail.com>>:
>
>
> Hi Chris.
>
>
> 1. Is -rc suffix a satisfied alternative to you?
> 2. This can be part of binary release topics. I read our policy to release
> sources only so I don't push an alert for doing so. But I do assume -rc
> suffix could be an improvement before the podling getting graduated.
>
>
> Best,
> tison.
>
>
>
>
> Christofer Dutz <christofer.dutz@c-ware.de <mailto:
> christofer.dutz@c-ware.de>> 于2023年7月4日周二 19:45写道：
>
>
> > Hi all,
> >
> > I don't think this procedure is ok according to our policies.
> >
> > Simply not listing a release on the project page will not help anyone
> > using this as a dependency.
> >
> > At least, every time I update a dependency, I never check the projects
> > page, if this is even a released version.
> >
> > Chris
> >
> >
> >
> > Am 04.07.23, 13:37 schrieb "tison" <wander4096@gmail.com <mailto:
> wander4096@gmail.com> <mailto:
> > wander4096@gmail.com <ma...@gmail.com>>>:
> >
> >
> > Here are four workflows to release Rust, Node.js, Python and Ruby
> libraries
> > to their conventional repository.
> >
> >
> > 1. Rust Cargo -
> >
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> >
> > >
> > 2. Python PyPi -
> >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> >
> > >
> > 3. Ruby Gems -
> >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> >
> > >
> > 4. Node.js npm -
> >
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> >
> > <
> >
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> >
> > >
> >
> >
> > All of them, different from the Apache Maven Nexus repository, are
> > maintained by third-party platforms. So we request a token and share it
> > among the Podling PMC via 1Password (a free team provision provided by
> the
> > team[1]).
> >
> >
> > > revoked
> >
> >
> > For the source releases, if the vote failed, it won't be copied to the
> > release svn directory.
> >
> >
> > For the binary releases, although all of these platforms should support
> -rc
> > in version tag, we release an X.Y.Z for each candidate and leave it there
> > if vote failed. The version won't be listed at the official page[2].
> >
> >
> > I ever advice the PPMC that using a -rc suffix would be better but they
> use
> > this way now for convenient development. As you can see, the version
> number
> > is 0.X so users should already use it at their risk. If it's requested, I
> > believe the PPMC would be glad to add a notice for which ones are Apache
> > voted releases or use a different version tag strategy to distinguish
> that.
> > There should not be any blocker technically.
> >
> >
> > OpenDAL has a release document[3] that you can refer to and do not
> hesitate
> > to open an issue if you find anything is unclear or unexpected.
> >
> >
> > Best,
> > tison.
> >
> >
> > [1] https://github.com/1Password/1password-teams-open-source/pull/742 <
> https://github.com/1Password/1password-teams-open-source/pull/742> <
> > https://github.com/1Password/1password-teams-open-source/pull/742> <
> https://github.com/1Password/1password-teams-open-source/pull/742>>
> > [2] https://opendal.apache.org/download <
> https://opendal.apache.org/download> <
> > https://opendal.apache.org/download> <
> https://opendal.apache.org/download>>
> > [3] https://opendal.apache.org/docs/contributing/release <
> https://opendal.apache.org/docs/contributing/release> <
> > https://opendal.apache.org/docs/contributing/release> <
> https://opendal.apache.org/docs/contributing/release>>
> >
> >
> >
> >
> >
> >
> > PJ Fanning <fanningpj@gmail.com <ma...@gmail.com> <mailto:
> fanningpj@gmail.com <ma...@gmail.com>>>
> > 于2023年7月4日周二 19:17写道：
> >
> >
> > > Hi Tison,
> > >
> > > Would it be possible to provide us with links to documentation about
> > > how you deploy your binary artifacts and how they can be revoked if a
> > > vote fails?
> > >
> > > I think this is useful for IPMC members when they are reviewing your
> > > release candidates. It's nice to review the binaries as well as the
> > > source artifacts, even if the source artifacts are the main point of
> > > the vote.
> > >
> > > When staging RCs for review, I tend to use
> > > * dist.apache.org (this is where the source artifacts go anyway)
> > > * repository.apache.org (jars)
> > >
> > > Files on dist.apache.org can be deleted when votes fail.
> > > With repository.apache.org, the release is a 2 phase process. You
> > > first push to 'staging' and then you can use its Nexus UI to drop or
> > > release the staged artifacts after the vote.
> > >
> > > OpenDAL is mainly in Rust but you also have a large number of language
> > > bindings (see libraries list [1]), existing and planned. So
> > > presumably, you are using a large number of different packaging tools
> > > for your binary releases. Many of us in the IPMC would not be familiar
> > > with all these packaging tools.
> > >
> > > You may already have documentation and if so, could you share a link?
> > >
> > > If there is no shareable documentation, would you be able to tell us
> > > which Crate Registry do you use for your RC Rust binaries? Do we have
> > > a custom registry that allows us to remove the binaries for releases
> > > that fail?
> > >
> > > Any information would be appreciated.
> > >
> > > Regards,
> > > PJ
> > >
> > > [1] https://github.com/apache/incubator-opendal <
> https://github.com/apache/incubator-opendal> <
> > https://github.com/apache/incubator-opendal> <
> https://github.com/apache/incubator-opendal>>
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <ma...@incubator.apache.org>
> > For additional commands, e-mail: general-help@incubator.apache.org
> <ma...@incubator.apache.org>
> >
>
>
>
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Tison,
Well, it definitely is better than without, however I am still not sure, if It's ok to still publish RCs without a vote.
Currently there's quite a bit of discussion on the matter of releasing binary artifacts, so I would call this part a bit in flux right now.
But hopefully someone else will be able to provide more information on this.
Chris
Am 04.07.23, 13:48 schrieb "tison" <wander4096@gmail.com <ma...@gmail.com>>:
Hi Chris.
1. Is -rc suffix a satisfied alternative to you?
2. This can be part of binary release topics. I read our policy to release
sources only so I don't push an alert for doing so. But I do assume -rc
suffix could be an improvement before the podling getting graduated.
Best,
tison.
Christofer Dutz <christofer.dutz@c-ware.de <ma...@c-ware.de>> 于2023年7月4日周二 19:45写道：
> Hi all,
>
> I don't think this procedure is ok according to our policies.
>
> Simply not listing a release on the project page will not help anyone
> using this as a dependency.
>
> At least, every time I update a dependency, I never check the projects
> page, if this is even a released version.
>
> Chris
>
>
>
> Am 04.07.23, 13:37 schrieb "tison" <wander4096@gmail.com <ma...@gmail.com> <mailto:
> wander4096@gmail.com <ma...@gmail.com>>>:
>
>
> Here are four workflows to release Rust, Node.js, Python and Ruby libraries
> to their conventional repository.
>
>
> 1. Rust Cargo -
>
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
> >
> 2. Python PyPi -
>
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
> >
> 3. Ruby Gems -
>
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml>
> >
> 4. Node.js npm -
>
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml>
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml>
> >
>
>
> All of them, different from the Apache Maven Nexus repository, are
> maintained by third-party platforms. So we request a token and share it
> among the Podling PMC via 1Password (a free team provision provided by the
> team[1]).
>
>
> > revoked
>
>
> For the source releases, if the vote failed, it won't be copied to the
> release svn directory.
>
>
> For the binary releases, although all of these platforms should support -rc
> in version tag, we release an X.Y.Z for each candidate and leave it there
> if vote failed. The version won't be listed at the official page[2].
>
>
> I ever advice the PPMC that using a -rc suffix would be better but they use
> this way now for convenient development. As you can see, the version number
> is 0.X so users should already use it at their risk. If it's requested, I
> believe the PPMC would be glad to add a notice for which ones are Apache
> voted releases or use a different version tag strategy to distinguish that.
> There should not be any blocker technically.
>
>
> OpenDAL has a release document[3] that you can refer to and do not hesitate
> to open an issue if you find anything is unclear or unexpected.
>
>
> Best,
> tison.
>
>
> [1] https://github.com/1Password/1password-teams-open-source/pull/742 <https://github.com/1Password/1password-teams-open-source/pull/742> <
> https://github.com/1Password/1password-teams-open-source/pull/742> <https://github.com/1Password/1password-teams-open-source/pull/742>>
> [2] https://opendal.apache.org/download <https://opendal.apache.org/download> <
> https://opendal.apache.org/download> <https://opendal.apache.org/download>>
> [3] https://opendal.apache.org/docs/contributing/release <https://opendal.apache.org/docs/contributing/release> <
> https://opendal.apache.org/docs/contributing/release> <https://opendal.apache.org/docs/contributing/release>>
>
>
>
>
>
>
> PJ Fanning <fanningpj@gmail.com <ma...@gmail.com> <mailto:fanningpj@gmail.com <ma...@gmail.com>>>
> 于2023年7月4日周二 19:17写道：
>
>
> > Hi Tison,
> >
> > Would it be possible to provide us with links to documentation about
> > how you deploy your binary artifacts and how they can be revoked if a
> > vote fails?
> >
> > I think this is useful for IPMC members when they are reviewing your
> > release candidates. It's nice to review the binaries as well as the
> > source artifacts, even if the source artifacts are the main point of
> > the vote.
> >
> > When staging RCs for review, I tend to use
> > * dist.apache.org (this is where the source artifacts go anyway)
> > * repository.apache.org (jars)
> >
> > Files on dist.apache.org can be deleted when votes fail.
> > With repository.apache.org, the release is a 2 phase process. You
> > first push to 'staging' and then you can use its Nexus UI to drop or
> > release the staged artifacts after the vote.
> >
> > OpenDAL is mainly in Rust but you also have a large number of language
> > bindings (see libraries list [1]), existing and planned. So
> > presumably, you are using a large number of different packaging tools
> > for your binary releases. Many of us in the IPMC would not be familiar
> > with all these packaging tools.
> >
> > You may already have documentation and if so, could you share a link?
> >
> > If there is no shareable documentation, would you be able to tell us
> > which Crate Registry do you use for your RC Rust binaries? Do we have
> > a custom registry that allows us to remove the binaries for releases
> > that fail?
> >
> > Any information would be appreciated.
> >
> > Regards,
> > PJ
> >
> > [1] https://github.com/apache/incubator-opendal <https://github.com/apache/incubator-opendal> <
> https://github.com/apache/incubator-opendal> <https://github.com/apache/incubator-opendal>>
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Hi Chris.
1. Is -rc suffix a satisfied alternative to you?
2. This can be part of binary release topics. I read our policy to release
sources only so I don't push an alert for doing so. But I do assume -rc
suffix could be an improvement before the podling getting graduated.
Best,
tison.
Christofer Dutz <ch...@c-ware.de> 于2023年7月4日周二 19:45写道：
> Hi all,
>
> I don't think this procedure is ok according to our policies.
>
> Simply not listing a release on the project page will not help anyone
> using this as a dependency.
>
> At least, every time I update a dependency, I never check the projects
> page, if this is even a released version.
>
> Chris
>
>
>
> Am 04.07.23, 13:37 schrieb "tison" <wander4096@gmail.com <mailto:
> wander4096@gmail.com>>:
>
>
> Here are four workflows to release Rust, Node.js, Python and Ruby libraries
> to their conventional repository.
>
>
> 1. Rust Cargo -
>
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> <
> https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
> >
> 2. Python PyPi -
>
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
> >
> 3. Ruby Gems -
>
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
> >
> 4. Node.js npm -
>
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> <
> https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
> >
>
>
> All of them, different from the Apache Maven Nexus repository, are
> maintained by third-party platforms. So we request a token and share it
> among the Podling PMC via 1Password (a free team provision provided by the
> team[1]).
>
>
> > revoked
>
>
> For the source releases, if the vote failed, it won't be copied to the
> release svn directory.
>
>
> For the binary releases, although all of these platforms should support -rc
> in version tag, we release an X.Y.Z for each candidate and leave it there
> if vote failed. The version won't be listed at the official page[2].
>
>
> I ever advice the PPMC that using a -rc suffix would be better but they use
> this way now for convenient development. As you can see, the version number
> is 0.X so users should already use it at their risk. If it's requested, I
> believe the PPMC would be glad to add a notice for which ones are Apache
> voted releases or use a different version tag strategy to distinguish that.
> There should not be any blocker technically.
>
>
> OpenDAL has a release document[3] that you can refer to and do not hesitate
> to open an issue if you find anything is unclear or unexpected.
>
>
> Best,
> tison.
>
>
> [1] https://github.com/1Password/1password-teams-open-source/pull/742 <
> https://github.com/1Password/1password-teams-open-source/pull/742>
> [2] https://opendal.apache.org/download <
> https://opendal.apache.org/download>
> [3] https://opendal.apache.org/docs/contributing/release <
> https://opendal.apache.org/docs/contributing/release>
>
>
>
>
>
>
> PJ Fanning <fanningpj@gmail.com <ma...@gmail.com>>
> 于2023年7月4日周二 19:17写道：
>
>
> > Hi Tison,
> >
> > Would it be possible to provide us with links to documentation about
> > how you deploy your binary artifacts and how they can be revoked if a
> > vote fails?
> >
> > I think this is useful for IPMC members when they are reviewing your
> > release candidates. It's nice to review the binaries as well as the
> > source artifacts, even if the source artifacts are the main point of
> > the vote.
> >
> > When staging RCs for review, I tend to use
> > * dist.apache.org (this is where the source artifacts go anyway)
> > * repository.apache.org (jars)
> >
> > Files on dist.apache.org can be deleted when votes fail.
> > With repository.apache.org, the release is a 2 phase process. You
> > first push to 'staging' and then you can use its Nexus UI to drop or
> > release the staged artifacts after the vote.
> >
> > OpenDAL is mainly in Rust but you also have a large number of language
> > bindings (see libraries list [1]), existing and planned. So
> > presumably, you are using a large number of different packaging tools
> > for your binary releases. Many of us in the IPMC would not be familiar
> > with all these packaging tools.
> >
> > You may already have documentation and if so, could you share a link?
> >
> > If there is no shareable documentation, would you be able to tell us
> > which Crate Registry do you use for your RC Rust binaries? Do we have
> > a custom registry that allows us to remove the binaries for releases
> > that fail?
> >
> > Any information would be appreciated.
> >
> > Regards,
> > PJ
> >
> > [1] https://github.com/apache/incubator-opendal <
> https://github.com/apache/incubator-opendal>
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
I don't think this procedure is ok according to our policies.
Simply not listing a release on the project page will not help anyone using this as a dependency.
At least, every time I update a dependency, I never check the projects page, if this is even a released version.
Chris
Am 04.07.23, 13:37 schrieb "tison" <wander4096@gmail.com <ma...@gmail.com>>:
Here are four workflows to release Rust, Node.js, Python and Ruby libraries
to their conventional repository.
1. Rust Cargo -
https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml>
2. Python PyPi -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml>
3. Ruby Gems -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml>
4. Node.js npm -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml>
All of them, different from the Apache Maven Nexus repository, are
maintained by third-party platforms. So we request a token and share it
among the Podling PMC via 1Password (a free team provision provided by the
team[1]).
> revoked
For the source releases, if the vote failed, it won't be copied to the
release svn directory.
For the binary releases, although all of these platforms should support -rc
in version tag, we release an X.Y.Z for each candidate and leave it there
if vote failed. The version won't be listed at the official page[2].
I ever advice the PPMC that using a -rc suffix would be better but they use
this way now for convenient development. As you can see, the version number
is 0.X so users should already use it at their risk. If it's requested, I
believe the PPMC would be glad to add a notice for which ones are Apache
voted releases or use a different version tag strategy to distinguish that.
There should not be any blocker technically.
OpenDAL has a release document[3] that you can refer to and do not hesitate
to open an issue if you find anything is unclear or unexpected.
Best,
tison.
[1] https://github.com/1Password/1password-teams-open-source/pull/742 <https://github.com/1Password/1password-teams-open-source/pull/742>
[2] https://opendal.apache.org/download <https://opendal.apache.org/download>
[3] https://opendal.apache.org/docs/contributing/release <https://opendal.apache.org/docs/contributing/release>
PJ Fanning <fanningpj@gmail.com <ma...@gmail.com>> 于2023年7月4日周二 19:17写道：
> Hi Tison,
>
> Would it be possible to provide us with links to documentation about
> how you deploy your binary artifacts and how they can be revoked if a
> vote fails?
>
> I think this is useful for IPMC members when they are reviewing your
> release candidates. It's nice to review the binaries as well as the
> source artifacts, even if the source artifacts are the main point of
> the vote.
>
> When staging RCs for review, I tend to use
> * dist.apache.org (this is where the source artifacts go anyway)
> * repository.apache.org (jars)
>
> Files on dist.apache.org can be deleted when votes fail.
> With repository.apache.org, the release is a 2 phase process. You
> first push to 'staging' and then you can use its Nexus UI to drop or
> release the staged artifacts after the vote.
>
> OpenDAL is mainly in Rust but you also have a large number of language
> bindings (see libraries list [1]), existing and planned. So
> presumably, you are using a large number of different packaging tools
> for your binary releases. Many of us in the IPMC would not be familiar
> with all these packaging tools.
>
> You may already have documentation and if so, could you share a link?
>
> If there is no shareable documentation, would you be able to tell us
> which Crate Registry do you use for your RC Rust binaries? Do we have
> a custom registry that allows us to remove the binaries for releases
> that fail?
>
> Any information would be appreciated.
>
> Regards,
> PJ
>
> [1] https://github.com/apache/incubator-opendal <https://github.com/apache/incubator-opendal>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Here are four workflows to release Rust, Node.js, Python and Ruby libraries
to their conventional repository.
1. Rust Cargo -
https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
2. Python PyPi -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
3. Ruby Gems -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
4. Node.js npm -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
All of them, different from the Apache Maven Nexus repository, are
maintained by third-party platforms. So we request a token and share it
among the Podling PMC via 1Password (a free team provision provided by the
team[1]).
> revoked
For the source releases, if the vote failed, it won't be copied to the
release svn directory.
For the binary releases, although all of these platforms should support -rc
in version tag, we release an X.Y.Z for each candidate and leave it there
if vote failed. The version won't be listed at the official page[2].
I ever advice the PPMC that using a -rc suffix would be better but they use
this way now for convenient development. As you can see, the version number
is 0.X so users should already use it at their risk. If it's requested, I
believe the PPMC would be glad to add a notice for which ones are Apache
voted releases or use a different version tag strategy to distinguish that.
There should not be any blocker technically.
OpenDAL has a release document[3] that you can refer to and do not hesitate
to open an issue if you find anything is unclear or unexpected.
Best,
tison.
[1] https://github.com/1Password/1password-teams-open-source/pull/742
[2] https://opendal.apache.org/download
[3] https://opendal.apache.org/docs/contributing/release
PJ Fanning <fa...@gmail.com> 于2023年7月4日周二 19:17写道：
> Hi Tison,
>
> Would it be possible to provide us with links to documentation about
> how you deploy your binary artifacts and how they can be revoked if a
> vote fails?
>
> I think this is useful for IPMC members when they are reviewing your
> release candidates. It's nice to review the binaries as well as the
> source artifacts, even if the source artifacts are the main point of
> the vote.
>
> When staging RCs for review, I tend to use
> * dist.apache.org (this is where the source artifacts go anyway)
> * repository.apache.org (jars)
>
> Files on dist.apache.org can be deleted when votes fail.
> With repository.apache.org, the release is a 2 phase process. You
> first push to 'staging' and then you can use its Nexus UI to drop or
> release the staged artifacts after the vote.
>
> OpenDAL is mainly in Rust but you also have a large number of language
> bindings (see libraries list [1]), existing and planned. So
> presumably, you are using a large number of different packaging tools
> for your binary releases. Many of us in the IPMC would not be familiar
> with all these packaging tools.
>
> You may already have documentation and if so, could you share a link?
>
> If there is no shareable documentation, would you be able to tell us
> which Crate Registry do you use for your RC Rust binaries? Do we have
> a custom registry that allows us to remove the binaries for releases
> that fail?
>
> Any information would be appreciated.
>
> Regards,
> PJ
>
> [1] https://github.com/apache/incubator-opendal
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Here are four workflows to release Rust, Node.js, Python and Ruby libraries
to their conventional repository.
1. Rust Cargo -
https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
2. Python PyPi -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml
3. Ruby Gems -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml
4. Node.js npm -
https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml
All of them, different from the Apache Maven Nexus repository, are
maintained by third-party platforms. So we request a token and share it
among the Podling PMC via 1Password (a free team provision provided by the
team[1]).
> revoked
For the source releases, if the vote failed, it won't be copied to the
release svn directory.
For the binary releases, although all of these platforms should support -rc
in version tag, we release an X.Y.Z for each candidate and leave it there
if vote failed. The version won't be listed at the official page[2].
I ever advice the PPMC that using a -rc suffix would be better but they use
this way now for convenient development. As you can see, the version number
is 0.X so users should already use it at their risk. If it's requested, I
believe the PPMC would be glad to add a notice for which ones are Apache
voted releases or use a different version tag strategy to distinguish that.
There should not be any blocker technically.
OpenDAL has a release document[3] that you can refer to and do not hesitate
to open an issue if you find anything is unclear or unexpected.
Best,
tison.
[1] https://github.com/1Password/1password-teams-open-source/pull/742
[2] https://opendal.apache.org/download
[3] https://opendal.apache.org/docs/contributing/release
PJ Fanning <fa...@gmail.com> 于2023年7月4日周二 19:17写道：
> Hi Tison,
>
> Would it be possible to provide us with links to documentation about
> how you deploy your binary artifacts and how they can be revoked if a
> vote fails?
>
> I think this is useful for IPMC members when they are reviewing your
> release candidates. It's nice to review the binaries as well as the
> source artifacts, even if the source artifacts are the main point of
> the vote.
>
> When staging RCs for review, I tend to use
> * dist.apache.org (this is where the source artifacts go anyway)
> * repository.apache.org (jars)
>
> Files on dist.apache.org can be deleted when votes fail.
> With repository.apache.org, the release is a 2 phase process. You
> first push to 'staging' and then you can use its Nexus UI to drop or
> release the staged artifacts after the vote.
>
> OpenDAL is mainly in Rust but you also have a large number of language
> bindings (see libraries list [1]), existing and planned. So
> presumably, you are using a large number of different packaging tools
> for your binary releases. Many of us in the IPMC would not be familiar
> with all these packaging tools.
>
> You may already have documentation and if so, could you share a link?
>
> If there is no shareable documentation, would you be able to tell us
> which Crate Registry do you use for your RC Rust binaries? Do we have
> a custom registry that allows us to remove the binaries for releases
> that fail?
>
> Any information would be appreciated.
>
> Regards,
> PJ
>
> [1] https://github.com/apache/incubator-opendal
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by PJ Fanning <fa...@gmail.com>.
Hi Tison,
Would it be possible to provide us with links to documentation about
how you deploy your binary artifacts and how they can be revoked if a
vote fails?
I think this is useful for IPMC members when they are reviewing your
release candidates. It's nice to review the binaries as well as the
source artifacts, even if the source artifacts are the main point of
the vote.
When staging RCs for review, I tend to use
* dist.apache.org (this is where the source artifacts go anyway)
* repository.apache.org (jars)
Files on dist.apache.org can be deleted when votes fail.
With repository.apache.org, the release is a 2 phase process. You
first push to 'staging' and then you can use its Nexus UI to drop or
release the staged artifacts after the vote.
OpenDAL is mainly in Rust but you also have a large number of language
bindings (see libraries list [1]), existing and planned. So
presumably, you are using a large number of different packaging tools
for your binary releases. Many of us in the IPMC would not be familiar
with all these packaging tools.
You may already have documentation and if so, could you share a link?
If there is no shareable documentation, would you be able to tell us
which Crate Registry do you use for your RC Rust binaries? Do we have
a custom registry that allows us to remove the binaries for releases
that fail?
Any information would be appreciated.
Regards,
PJ
[1] https://github.com/apache/incubator-opendal
On Tue, 4 Jul 2023 at 05:29, Greg Stein <gs...@gmail.com> wrote:
>
> Tison: STOP cross-posting between private and public lists. You have been
> advised to stop doing so once, and this is now TWICE. No more.
>
> Regards,
> Greg Stein
> Infrastructure Administrator, ASF
>
>
> On Mon, Jul 3, 2023 at 6:01 AM tison <wa...@gmail.com> wrote:
>
> > Hi Daniel,
> >
> > Thanks for your information! That can be an alternative for the signing
> > key.
> >
> > Right now the blocker I met is 403 from the Nexus server which I suspect is
> > the lack of permissions from the Nexus credentials. Could you confirm or
> > correct it?
> >
> > Best,
> > tison.
> >
> >
> > tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
> >
> > > Hi PJ,
> > >
> > > Thanks for sharing your thoughts!
> > >
> > > For signing key, it's a resolved topic from my perspective. I use -
> > >
> > > 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
> > > 2. Load the key from our 1password service, while since it's a specific
> > > key, I feel comfortable to pass it to INFRA member and configure as a
> > > secret alternatively.
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
> > >
> > >
> > > PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
> > >
> > >> Adding the Incubator general list.
> > >>
> > >> My view would be that non-snapshot binary artifacts should be signed
> > >> with a personal signing key - ideally the signing key that was used to
> > >> release the related source release. Unfortunately, this would mean
> > >> adding a user's signing key to the Apache GitHub account as a secret
> > >> so that the automated GitHub Action job could access it. I don't see
> > >> how we could allow personal signing keys to be added like this.
> > >>
> > >> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
> > >> >
> > >> > cc security
> > >> >
> > >> > Missed in the first place.
> > >> >
> > >> > Best,
> > >> > tison.
> > >> >
> > >> >
> > >> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> > >> >>
> > >> >> Hi security team members,
> > >> >>
> > >> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
> > >> >>
> > >> >> I already verify that GitHub Actions work well for automatically
> > >> deploying OpenDAL Java binding[2].
> > >> >>
> > >> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
> > >> problem that deploying Maven projects requires NEXUS credentials. For my
> > >> personal repo, I can config my Apache ID and password as secrets. For
> > >> apache repos, it requires handing over the credentials to INFRA team
> > >> member. Even I can trust the member, it's a bit less than awesome.
> > >> >>
> > >> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
> > >> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
> > >> INFRA member suggested me to consult security team for approval for such
> > >> automatic deployment and they would help to grant related permissions if
> > >> approved.
> > >> >>
> > >> >> Please help review the request to support ASF projects deploying
> > Maven
> > >> project via GitHub Actions.
> > >> >>
> > >> >> Best,
> > >> >> tison.
> > >> >>
> > >> >> [1] http://github.com/apache/incubator-opendal
> > >> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> > >> >> [3]
> > >>
> > https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: general-help@incubator.apache.org
> > >>
> > >>
> >
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by PJ Fanning <fa...@gmail.com>.
Hi Tison,
Would it be possible to provide us with links to documentation about
how you deploy your binary artifacts and how they can be revoked if a
vote fails?
I think this is useful for IPMC members when they are reviewing your
release candidates. It's nice to review the binaries as well as the
source artifacts, even if the source artifacts are the main point of
the vote.
When staging RCs for review, I tend to use
* dist.apache.org (this is where the source artifacts go anyway)
* repository.apache.org (jars)
Files on dist.apache.org can be deleted when votes fail.
With repository.apache.org, the release is a 2 phase process. You
first push to 'staging' and then you can use its Nexus UI to drop or
release the staged artifacts after the vote.
OpenDAL is mainly in Rust but you also have a large number of language
bindings (see libraries list [1]), existing and planned. So
presumably, you are using a large number of different packaging tools
for your binary releases. Many of us in the IPMC would not be familiar
with all these packaging tools.
You may already have documentation and if so, could you share a link?
If there is no shareable documentation, would you be able to tell us
which Crate Registry do you use for your RC Rust binaries? Do we have
a custom registry that allows us to remove the binaries for releases
that fail?
Any information would be appreciated.
Regards,
PJ
[1] https://github.com/apache/incubator-opendal
On Tue, 4 Jul 2023 at 05:29, Greg Stein <gs...@gmail.com> wrote:
>
> Tison: STOP cross-posting between private and public lists. You have been
> advised to stop doing so once, and this is now TWICE. No more.
>
> Regards,
> Greg Stein
> Infrastructure Administrator, ASF
>
>
> On Mon, Jul 3, 2023 at 6:01 AM tison <wa...@gmail.com> wrote:
>
> > Hi Daniel,
> >
> > Thanks for your information! That can be an alternative for the signing
> > key.
> >
> > Right now the blocker I met is 403 from the Nexus server which I suspect is
> > the lack of permissions from the Nexus credentials. Could you confirm or
> > correct it?
> >
> > Best,
> > tison.
> >
> >
> > tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
> >
> > > Hi PJ,
> > >
> > > Thanks for sharing your thoughts!
> > >
> > > For signing key, it's a resolved topic from my perspective. I use -
> > >
> > > 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
> > > 2. Load the key from our 1password service, while since it's a specific
> > > key, I feel comfortable to pass it to INFRA member and configure as a
> > > secret alternatively.
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
> > >
> > >
> > > PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
> > >
> > >> Adding the Incubator general list.
> > >>
> > >> My view would be that non-snapshot binary artifacts should be signed
> > >> with a personal signing key - ideally the signing key that was used to
> > >> release the related source release. Unfortunately, this would mean
> > >> adding a user's signing key to the Apache GitHub account as a secret
> > >> so that the automated GitHub Action job could access it. I don't see
> > >> how we could allow personal signing keys to be added like this.
> > >>
> > >> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
> > >> >
> > >> > cc security
> > >> >
> > >> > Missed in the first place.
> > >> >
> > >> > Best,
> > >> > tison.
> > >> >
> > >> >
> > >> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> > >> >>
> > >> >> Hi security team members,
> > >> >>
> > >> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
> > >> >>
> > >> >> I already verify that GitHub Actions work well for automatically
> > >> deploying OpenDAL Java binding[2].
> > >> >>
> > >> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
> > >> problem that deploying Maven projects requires NEXUS credentials. For my
> > >> personal repo, I can config my Apache ID and password as secrets. For
> > >> apache repos, it requires handing over the credentials to INFRA team
> > >> member. Even I can trust the member, it's a bit less than awesome.
> > >> >>
> > >> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
> > >> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
> > >> INFRA member suggested me to consult security team for approval for such
> > >> automatic deployment and they would help to grant related permissions if
> > >> approved.
> > >> >>
> > >> >> Please help review the request to support ASF projects deploying
> > Maven
> > >> project via GitHub Actions.
> > >> >>
> > >> >> Best,
> > >> >> tison.
> > >> >>
> > >> >> [1] http://github.com/apache/incubator-opendal
> > >> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> > >> >> [3]
> > >>
> > https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: general-help@incubator.apache.org
> > >>
> > >>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by Greg Stein <gs...@gmail.com>.
Tison: STOP cross-posting between private and public lists. You have been
advised to stop doing so once, and this is now TWICE. No more.
Regards,
Greg Stein
Infrastructure Administrator, ASF
On Mon, Jul 3, 2023 at 6:01 AM tison <wa...@gmail.com> wrote:
> Hi Daniel,
>
> Thanks for your information! That can be an alternative for the signing
> key.
>
> Right now the blocker I met is 403 from the Nexus server which I suspect is
> the lack of permissions from the Nexus credentials. Could you confirm or
> correct it?
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
>
> > Hi PJ,
> >
> > Thanks for sharing your thoughts!
> >
> > For signing key, it's a resolved topic from my perspective. I use -
> >
> > 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
> > 2. Load the key from our 1password service, while since it's a specific
> > key, I feel comfortable to pass it to INFRA member and configure as a
> > secret alternatively.
> >
> > Best,
> > tison.
> >
> > [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
> >
> >
> > PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
> >
> >> Adding the Incubator general list.
> >>
> >> My view would be that non-snapshot binary artifacts should be signed
> >> with a personal signing key - ideally the signing key that was used to
> >> release the related source release. Unfortunately, this would mean
> >> adding a user's signing key to the Apache GitHub account as a secret
> >> so that the automated GitHub Action job could access it. I don't see
> >> how we could allow personal signing keys to be added like this.
> >>
> >> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
> >> >
> >> > cc security
> >> >
> >> > Missed in the first place.
> >> >
> >> > Best,
> >> > tison.
> >> >
> >> >
> >> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> >> >>
> >> >> Hi security team members,
> >> >>
> >> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
> >> >>
> >> >> I already verify that GitHub Actions work well for automatically
> >> deploying OpenDAL Java binding[2].
> >> >>
> >> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
> >> problem that deploying Maven projects requires NEXUS credentials. For my
> >> personal repo, I can config my Apache ID and password as secrets. For
> >> apache repos, it requires handing over the credentials to INFRA team
> >> member. Even I can trust the member, it's a bit less than awesome.
> >> >>
> >> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
> >> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
> >> INFRA member suggested me to consult security team for approval for such
> >> automatic deployment and they would help to grant related permissions if
> >> approved.
> >> >>
> >> >> Please help review the request to support ASF projects deploying
> Maven
> >> project via GitHub Actions.
> >> >>
> >> >> Best,
> >> >> tison.
> >> >>
> >> >> [1] http://github.com/apache/incubator-opendal
> >> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> >> >> [3]
> >>
> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Update mailing list. Or if I should start a new thread totally?
Best,
tison.
tison <wa...@gmail.com> 于2023年7月3日周一 19:00写道：
> Hi Daniel,
>
> Thanks for your information! That can be an alternative for the signing
> key.
>
> Right now the blocker I met is 403 from the Nexus server which I suspect
> is the lack of permissions from the Nexus credentials. Could you confirm or
> correct it?
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
>
>> Hi PJ,
>>
>> Thanks for sharing your thoughts!
>>
>> For signing key, it's a resolved topic from my perspective. I use -
>>
>> 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
>> 2. Load the key from our 1password service, while since it's a specific
>> key, I feel comfortable to pass it to INFRA member and configure as a
>> secret alternatively.
>>
>> Best,
>> tison.
>>
>> [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
>>
>>
>> PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
>>
>>> Adding the Incubator general list.
>>>
>>> My view would be that non-snapshot binary artifacts should be signed
>>> with a personal signing key - ideally the signing key that was used to
>>> release the related source release. Unfortunately, this would mean
>>> adding a user's signing key to the Apache GitHub account as a secret
>>> so that the automated GitHub Action job could access it. I don't see
>>> how we could allow personal signing keys to be added like this.
>>>
>>> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
>>> >
>>> > cc security
>>> >
>>> > Missed in the first place.
>>> >
>>> > Best,
>>> > tison.
>>> >
>>> >
>>> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
>>> >>
>>> >> Hi security team members,
>>> >>
>>> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
>>> >>
>>> >> I already verify that GitHub Actions work well for automatically
>>> deploying OpenDAL Java binding[2].
>>> >>
>>> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
>>> problem that deploying Maven projects requires NEXUS credentials. For my
>>> personal repo, I can config my Apache ID and password as secrets. For
>>> apache repos, it requires handing over the credentials to INFRA team
>>> member. Even I can trust the member, it's a bit less than awesome.
>>> >>
>>> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
>>> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
>>> INFRA member suggested me to consult security team for approval for such
>>> automatic deployment and they would help to grant related permissions if
>>> approved.
>>> >>
>>> >> Please help review the request to support ASF projects deploying
>>> Maven project via GitHub Actions.
>>> >>
>>> >> Best,
>>> >> tison.
>>> >>
>>> >> [1] http://github.com/apache/incubator-opendal
>>> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
>>> >> [3]
>>> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Update mailing list. Or if I should start a new thread totally?
Best,
tison.
tison <wa...@gmail.com> 于2023年7月3日周一 19:00写道：
> Hi Daniel,
>
> Thanks for your information! That can be an alternative for the signing
> key.
>
> Right now the blocker I met is 403 from the Nexus server which I suspect
> is the lack of permissions from the Nexus credentials. Could you confirm or
> correct it?
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
>
>> Hi PJ,
>>
>> Thanks for sharing your thoughts!
>>
>> For signing key, it's a resolved topic from my perspective. I use -
>>
>> 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
>> 2. Load the key from our 1password service, while since it's a specific
>> key, I feel comfortable to pass it to INFRA member and configure as a
>> secret alternatively.
>>
>> Best,
>> tison.
>>
>> [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
>>
>>
>> PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
>>
>>> Adding the Incubator general list.
>>>
>>> My view would be that non-snapshot binary artifacts should be signed
>>> with a personal signing key - ideally the signing key that was used to
>>> release the related source release. Unfortunately, this would mean
>>> adding a user's signing key to the Apache GitHub account as a secret
>>> so that the automated GitHub Action job could access it. I don't see
>>> how we could allow personal signing keys to be added like this.
>>>
>>> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
>>> >
>>> > cc security
>>> >
>>> > Missed in the first place.
>>> >
>>> > Best,
>>> > tison.
>>> >
>>> >
>>> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
>>> >>
>>> >> Hi security team members,
>>> >>
>>> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
>>> >>
>>> >> I already verify that GitHub Actions work well for automatically
>>> deploying OpenDAL Java binding[2].
>>> >>
>>> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
>>> problem that deploying Maven projects requires NEXUS credentials. For my
>>> personal repo, I can config my Apache ID and password as secrets. For
>>> apache repos, it requires handing over the credentials to INFRA team
>>> member. Even I can trust the member, it's a bit less than awesome.
>>> >>
>>> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
>>> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
>>> INFRA member suggested me to consult security team for approval for such
>>> automatic deployment and they would help to grant related permissions if
>>> approved.
>>> >>
>>> >> Please help review the request to support ASF projects deploying
>>> Maven project via GitHub Actions.
>>> >>
>>> >> Best,
>>> >> tison.
>>> >>
>>> >> [1] http://github.com/apache/incubator-opendal
>>> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
>>> >> [3]
>>> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by Greg Stein <gs...@gmail.com>.
Tison: STOP cross-posting between private and public lists. You have been
advised to stop doing so once, and this is now TWICE. No more.
Regards,
Greg Stein
Infrastructure Administrator, ASF
On Mon, Jul 3, 2023 at 6:01 AM tison <wa...@gmail.com> wrote:
> Hi Daniel,
>
> Thanks for your information! That can be an alternative for the signing
> key.
>
> Right now the blocker I met is 403 from the Nexus server which I suspect is
> the lack of permissions from the Nexus credentials. Could you confirm or
> correct it?
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
>
> > Hi PJ,
> >
> > Thanks for sharing your thoughts!
> >
> > For signing key, it's a resolved topic from my perspective. I use -
> >
> > 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
> > 2. Load the key from our 1password service, while since it's a specific
> > key, I feel comfortable to pass it to INFRA member and configure as a
> > secret alternatively.
> >
> > Best,
> > tison.
> >
> > [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
> >
> >
> > PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
> >
> >> Adding the Incubator general list.
> >>
> >> My view would be that non-snapshot binary artifacts should be signed
> >> with a personal signing key - ideally the signing key that was used to
> >> release the related source release. Unfortunately, this would mean
> >> adding a user's signing key to the Apache GitHub account as a secret
> >> so that the automated GitHub Action job could access it. I don't see
> >> how we could allow personal signing keys to be added like this.
> >>
> >> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
> >> >
> >> > cc security
> >> >
> >> > Missed in the first place.
> >> >
> >> > Best,
> >> > tison.
> >> >
> >> >
> >> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> >> >>
> >> >> Hi security team members,
> >> >>
> >> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
> >> >>
> >> >> I already verify that GitHub Actions work well for automatically
> >> deploying OpenDAL Java binding[2].
> >> >>
> >> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
> >> problem that deploying Maven projects requires NEXUS credentials. For my
> >> personal repo, I can config my Apache ID and password as secrets. For
> >> apache repos, it requires handing over the credentials to INFRA team
> >> member. Even I can trust the member, it's a bit less than awesome.
> >> >>
> >> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
> >> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
> >> INFRA member suggested me to consult security team for approval for such
> >> automatic deployment and they would help to grant related permissions if
> >> approved.
> >> >>
> >> >> Please help review the request to support ASF projects deploying
> Maven
> >> project via GitHub Actions.
> >> >>
> >> >> Best,
> >> >> tison.
> >> >>
> >> >> [1] http://github.com/apache/incubator-opendal
> >> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> >> >> [3]
> >>
> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Hi Daniel,
Thanks for your information! That can be an alternative for the signing key.
Right now the blocker I met is 403 from the Nexus server which I suspect is
the lack of permissions from the Nexus credentials. Could you confirm or
correct it?
Best,
tison.
tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
> Hi PJ,
>
> Thanks for sharing your thoughts!
>
> For signing key, it's a resolved topic from my perspective. I use -
>
> 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
> 2. Load the key from our 1password service, while since it's a specific
> key, I feel comfortable to pass it to INFRA member and configure as a
> secret alternatively.
>
> Best,
> tison.
>
> [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
>
>
> PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
>
>> Adding the Incubator general list.
>>
>> My view would be that non-snapshot binary artifacts should be signed
>> with a personal signing key - ideally the signing key that was used to
>> release the related source release. Unfortunately, this would mean
>> adding a user's signing key to the Apache GitHub account as a secret
>> so that the automated GitHub Action job could access it. I don't see
>> how we could allow personal signing keys to be added like this.
>>
>> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
>> >
>> > cc security
>> >
>> > Missed in the first place.
>> >
>> > Best,
>> > tison.
>> >
>> >
>> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
>> >>
>> >> Hi security team members,
>> >>
>> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
>> >>
>> >> I already verify that GitHub Actions work well for automatically
>> deploying OpenDAL Java binding[2].
>> >>
>> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
>> problem that deploying Maven projects requires NEXUS credentials. For my
>> personal repo, I can config my Apache ID and password as secrets. For
>> apache repos, it requires handing over the credentials to INFRA team
>> member. Even I can trust the member, it's a bit less than awesome.
>> >>
>> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
>> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
>> INFRA member suggested me to consult security team for approval for such
>> automatic deployment and they would help to grant related permissions if
>> approved.
>> >>
>> >> Please help review the request to support ASF projects deploying Maven
>> project via GitHub Actions.
>> >>
>> >> Best,
>> >> tison.
>> >>
>> >> [1] http://github.com/apache/incubator-opendal
>> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
>> >> [3]
>> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Hi Daniel,
Thanks for your information! That can be an alternative for the signing key.
Right now the blocker I met is 403 from the Nexus server which I suspect is
the lack of permissions from the Nexus credentials. Could you confirm or
correct it?
Best,
tison.
tison <wa...@gmail.com> 于2023年7月3日周一 18:58写道：
> Hi PJ,
>
> Thanks for sharing your thoughts!
>
> For signing key, it's a resolved topic from my perspective. I use -
>
> 1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
> 2. Load the key from our 1password service, while since it's a specific
> key, I feel comfortable to pass it to INFRA member and configure as a
> secret alternatively.
>
> Best,
> tison.
>
> [1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
>
>
> PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
>
>> Adding the Incubator general list.
>>
>> My view would be that non-snapshot binary artifacts should be signed
>> with a personal signing key - ideally the signing key that was used to
>> release the related source release. Unfortunately, this would mean
>> adding a user's signing key to the Apache GitHub account as a secret
>> so that the automated GitHub Action job could access it. I don't see
>> how we could allow personal signing keys to be added like this.
>>
>> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
>> >
>> > cc security
>> >
>> > Missed in the first place.
>> >
>> > Best,
>> > tison.
>> >
>> >
>> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
>> >>
>> >> Hi security team members,
>> >>
>> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
>> >>
>> >> I already verify that GitHub Actions work well for automatically
>> deploying OpenDAL Java binding[2].
>> >>
>> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
>> problem that deploying Maven projects requires NEXUS credentials. For my
>> personal repo, I can config my Apache ID and password as secrets. For
>> apache repos, it requires handing over the credentials to INFRA team
>> member. Even I can trust the member, it's a bit less than awesome.
>> >>
>> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
>> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
>> INFRA member suggested me to consult security team for approval for such
>> automatic deployment and they would help to grant related permissions if
>> approved.
>> >>
>> >> Please help review the request to support ASF projects deploying Maven
>> project via GitHub Actions.
>> >>
>> >> Best,
>> >> tison.
>> >>
>> >> [1] http://github.com/apache/incubator-opendal
>> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
>> >> [3]
>> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Hi PJ,
Thanks for sharing your thoughts!
For signing key, it's a resolved topic from my perspective. I use -
1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
2. Load the key from our 1password service, while since it's a specific
key, I feel comfortable to pass it to INFRA member and configure as a
secret alternatively.
Best,
tison.
[1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
> Adding the Incubator general list.
>
> My view would be that non-snapshot binary artifacts should be signed
> with a personal signing key - ideally the signing key that was used to
> release the related source release. Unfortunately, this would mean
> adding a user's signing key to the Apache GitHub account as a secret
> so that the automated GitHub Action job could access it. I don't see
> how we could allow personal signing keys to be added like this.
>
> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
> >
> > cc security
> >
> > Missed in the first place.
> >
> > Best,
> > tison.
> >
> >
> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> >>
> >> Hi security team members,
> >>
> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
> >>
> >> I already verify that GitHub Actions work well for automatically
> deploying OpenDAL Java binding[2].
> >>
> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
> problem that deploying Maven projects requires NEXUS credentials. For my
> personal repo, I can config my Apache ID and password as secrets. For
> apache repos, it requires handing over the credentials to INFRA team
> member. Even I can trust the member, it's a bit less than awesome.
> >>
> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
> INFRA member suggested me to consult security team for approval for such
> automatic deployment and they would help to grant related permissions if
> approved.
> >>
> >> Please help review the request to support ASF projects deploying Maven
> project via GitHub Actions.
> >>
> >> Best,
> >> tison.
> >>
> >> [1] http://github.com/apache/incubator-opendal
> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> >> [3]
> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Hi PJ,
Thanks for sharing your thoughts!
For signing key, it's a resolved topic from my perspective. I use -
1. A signing key commented with OPENDAL CODE AUTO SIGNING KEY[1]
2. Load the key from our 1password service, while since it's a specific
key, I feel comfortable to pass it to INFRA member and configure as a
secret alternatively.
Best,
tison.
[1] https://dist.apache.org/repos/dist/release/incubator/opendal/KEYS
PJ Fanning <fa...@apache.org> 于2023年7月3日周一 18:52写道：
> Adding the Incubator general list.
>
> My view would be that non-snapshot binary artifacts should be signed
> with a personal signing key - ideally the signing key that was used to
> release the related source release. Unfortunately, this would mean
> adding a user's signing key to the Apache GitHub account as a secret
> so that the automated GitHub Action job could access it. I don't see
> how we could allow personal signing keys to be added like this.
>
> On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
> >
> > cc security
> >
> > Missed in the first place.
> >
> > Best,
> > tison.
> >
> >
> > tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> >>
> >> Hi security team members,
> >>
> >> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
> >>
> >> I already verify that GitHub Actions work well for automatically
> deploying OpenDAL Java binding[2].
> >>
> >> When integrating it with upstream (apache/incuabtor-opendal), I met a
> problem that deploying Maven projects requires NEXUS credentials. For my
> personal repo, I can config my Apache ID and password as secrets. For
> apache repos, it requires handing over the credentials to INFRA team
> member. Even I can trust the member, it's a bit less than awesome.
> >>
> >> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and
> NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only.
> INFRA member suggested me to consult security team for approval for such
> automatic deployment and they would help to grant related permissions if
> approved.
> >>
> >> Please help review the request to support ASF projects deploying Maven
> project via GitHub Actions.
> >>
> >> Best,
> >> tison.
> >>
> >> [1] http://github.com/apache/incubator-opendal
> >> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> >> [3]
> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by PJ Fanning <fa...@apache.org>.
Adding the Incubator general list.
My view would be that non-snapshot binary artifacts should be signed
with a personal signing key - ideally the signing key that was used to
release the related source release. Unfortunately, this would mean
adding a user's signing key to the Apache GitHub account as a secret
so that the automated GitHub Action job could access it. I don't see
how we could allow personal signing keys to be added like this.
On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
>
> cc security
>
> Missed in the first place.
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
>>
>> Hi security team members,
>>
>> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
>>
>> I already verify that GitHub Actions work well for automatically deploying OpenDAL Java binding[2].
>>
>> When integrating it with upstream (apache/incuabtor-opendal), I met a problem that deploying Maven projects requires NEXUS credentials. For my personal repo, I can config my Apache ID and password as secrets. For apache repos, it requires handing over the credentials to INFRA team member. Even I can trust the member, it's a bit less than awesome.
>>
>> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only. INFRA member suggested me to consult security team for approval for such automatic deployment and they would help to grant related permissions if approved.
>>
>> Please help review the request to support ASF projects deploying Maven project via GitHub Actions.
>>
>> Best,
>> tison.
>>
>> [1] http://github.com/apache/incubator-opendal
>> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
>> [3] https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
>>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by PJ Fanning <fa...@apache.org>.
Adding the Incubator general list.
My view would be that non-snapshot binary artifacts should be signed
with a personal signing key - ideally the signing key that was used to
release the related source release. Unfortunately, this would mean
adding a user's signing key to the Apache GitHub account as a secret
so that the automated GitHub Action job could access it. I don't see
how we could allow personal signing keys to be added like this.
On Mon, 3 Jul 2023 at 10:18, tison <wa...@gmail.com> wrote:
>
> cc security
>
> Missed in the first place.
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
>>
>> Hi security team members,
>>
>> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
>>
>> I already verify that GitHub Actions work well for automatically deploying OpenDAL Java binding[2].
>>
>> When integrating it with upstream (apache/incuabtor-opendal), I met a problem that deploying Maven projects requires NEXUS credentials. For my personal repo, I can config my Apache ID and password as secrets. For apache repos, it requires handing over the credentials to INFRA team member. Even I can trust the member, it's a bit less than awesome.
>>
>> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and NEXUS_PW for doing so[3]. But it's limited to deploying snapshots only. INFRA member suggested me to consult security team for approval for such automatic deployment and they would help to grant related permissions if approved.
>>
>> Please help review the request to support ASF projects deploying Maven project via GitHub Actions.
>>
>> Best,
>> tison.
>>
>> [1] http://github.com/apache/incubator-opendal
>> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
>> [3] https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
Thank you Volkan and Daniel!
Checked INFRA-24051[1], I know that for releasing OpenDAL to the release
repository rather than the staging repository, I need to file a ticket for
a new pair of credentials.
However, I don't see any attached security team approval there. Can you
share the context with security team?
@Daniel - prove the reproducibility of these artifacts to the security team
How can I achieve this? Or what mailing list should I use to contact the
security team for advice and approval?
Best,
tison.
[1] https://issues.apache.org/jira/browse/INFRA-24051
Daniel Gruno <hu...@apache.org> 于2023年7月3日周一 19:10写道：
> On 2023-07-03 13:03, Volkan Yazıcı wrote:
> > We successfully employ the very same "deploy to Maven repository from CI
> > for both snapshots and releases" practice for `logging-log4j-tools` and
> > `logging-log4j-transform` repositories. In essence, you need the
> > following secrets:
> >
> > 1. `NEXUS_USER` and `NEXUS_PW` GitHub secrets to allow CI deployments
> > to Nexus *snapshots* repository (INFRA-24535)
> > 2. `*_STAGE_DEPLOYER_PW` and `*_STAGE_DEPLOYER_USER` GitHub secrets to
> > allow CI deployments to Nexus *staging* repository (INFRA-24051)
> > 3. `GPG_SECRET_KEY` GitHub secret storing the private signing key
> > (INFRA-23996)
> >
> > I had stated earlier to INFRA
> > <https://issues.apache.org/jira/browse/INFRA-23996> the approval of
> Mark
> > J. Cox, the VP of Security, on this deployment practice
> > <https://lists.apache.org/thread/t1fbn11m70sy9df86xgzzp0fllg38p9q>. I
> am
> > not able to understand why this needs to be re-evaluated on a request
> > basis. In particular, given Nexus is not an official ASF distribution
> > medium, but merely a convenience for projects.
>
> It is not on a request basis, but rather project basis. We (infra) do
> not have any insights or experience with regards to OpenDAL and their
> release mechanisms, nor do we honestly know all the different Maven
> verbiage. If this is solely for non-release snapshots, then this needs
> to be communicated to us. The specific request reads as if they are
> requesting access to release official packages via CI, which would (as
> far as I am aware) require them to prove the reproducibility of these
> artifacts to the security team.
>
> >
> > Note that you need to make sure that the released artifacts are
> > reproducible. (Again, see `logging-log4j-tools` for inspiration
> > <
> https://github.com/apache/logging-log4j-tools/blob/master/.github/workflows/build.yml#L80>.)
> Otherwise, PMC cannot verify the integrity of a CI-produced release.
> >
> >
> > On Mon, Jul 3, 2023 at 11:18 AM tison <wander4096@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > cc security
> >
> > Missed in the first place.
> >
> > Best,
> > tison.
> >
> >
> > tison <wander4096@gmail.com <ma...@gmail.com>> 于2023年6
> > 月29日周四 22:21写道：
> >
> > Hi security team members,
> >
> > I'm tison from OpenDAL Podling[1], a Rust lib providing Java
> > binding.
> >
> > I already verify that GitHub Actions work well for automatically
> > deploying OpenDAL Java binding[2].
> >
> > When integrating it with upstream (apache/incuabtor-opendal), I
> > met a problem that deploying Maven projects requires NEXUS
> > credentials. For my personal repo, I can config my Apache ID and
> > password as secrets. For apache repos, it requires handing over
> > the credentials to INFRA team member. Even I can trust the
> > member, it's a bit less than awesome.
> >
> > Fortunately, INFRA provides two org-wise secrets NEXUS_USER
> > and NEXUS_PW for doing so[3]. But it's limited to deploying
> > snapshots only. INFRA member suggested me to consult security
> > team for approval for such automatic deployment and they would
> > help to grant related permissions if approved.
> >
> > Please help review the request to support ASF projects deploying
> > Maven project via GitHub Actions.
> >
> > Best,
> > tison.
> >
> > [1] http://github.com/apache/incubator-opendal
> > <http://github.com/apache/incubator-opendal>
> > [2]
> > https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> > <https://github.com/tisonkun/ci-opendal/actions/runs/5326589752>
> > [3]
> >
> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> <
> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
> >
> >
>
>
Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions
Posted by tison <wa...@gmail.com>.
cc security
Missed in the first place.
Best,
tison.
tison <wa...@gmail.com> 于2023年6月29日周四 22:21写道：
> Hi security team members,
>
> I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.
>
> I already verify that GitHub Actions work well for automatically deploying
> OpenDAL Java binding[2].
>
> When integrating it with upstream (apache/incuabtor-opendal), I met a
> problem that deploying Maven projects requires NEXUS credentials. For my
> personal repo, I can config my Apache ID and password as secrets. For
> apache repos, it requires handing over the credentials to INFRA team
> member. Even I can trust the member, it's a bit less than awesome.
>
> Fortunately, INFRA provides two org-wise secrets NEXUS_USER and NEXUS_PW
> for doing so[3]. But it's limited to deploying snapshots only. INFRA member
> suggested me to consult security team for approval for such automatic
> deployment and they would help to grant related permissions if approved.
>
> Please help review the request to support ASF projects deploying Maven
> project via GitHub Actions.
>
> Best,
> tison.
>
> [1] http://github.com/apache/incubator-opendal
> [2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
> [3]
> https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192
>
>