Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-04 Thread Vladimir Sitnikov 
> 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

2023-07-04 Thread tison 
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  于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"  wander4...@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.d...@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"  wander4...@gmail.com>  > wander4...@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.d...@c-ware.de>  > christofer.d...@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"  wander4...@gmail.com>  > wander4...@gmail.com >  > > wander4...@gmail.com   wander4...@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
> >
> > <
> >
>

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-04 Thread Christofer Dutz 
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" mailto:wander4...@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 mailto:christofer.d...@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"    wander4...@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 mailto:christofer.d...@c-ware.de> 
>  christofer.d...@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"  >   wander4...@gmail.com >  > wander4...@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
>  
> 
> <
>

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-04 Thread tison 
> 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  于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"  wander4...@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.d...@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"  wander4...@gmail.com>  > wander4...@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> <
> >

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-04 Thread Christofer Dutz 
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" mailto:wander4...@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 mailto:christofer.d...@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"    wander4...@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> 
>

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-04 Thread tison 
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  于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"  wander4...@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 mailto:fannin...@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

2023-07-04 Thread Christofer Dutz 
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" mailto:wander4...@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 mailto:fannin...@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 
> 
>




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-04 Thread tison 
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  于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

2023-07-04 Thread PJ Fanning 
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  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  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  于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  于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  wrote:
> > >> >
> > >> > cc security
> > >> >
> > >> > Missed in the first place.
> > >> >
> > >> > Best,
> > >> > tison.
> > >> >
> > >> >
> > >> > tison  于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

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-03 Thread Greg Stein 
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  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  于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  于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  wrote:
> >> >
> >> > cc security
> >> >
> >> > Missed in the first place.
> >> >
> >> > Best,
> >> > tison.
> >> >
> >> >
> >> > tison  于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-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-03 Thread PJ Fanning 
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  wrote:
>
> Update mailing list. Or if I should start a new thread totally?
>
> Best,
> tison.
>
>
> tison  于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  于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  于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  wrote:
> >>> >
> >>> > cc security
> >>> >
> >>> > Missed in the first place.
> >>> >
> >>> > Best,
> >>> > tison.
> >>> >
> >>> >
> >>> > tison  于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-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-03 Thread tison 
Update mailing list. Or if I should start a new thread totally?

Best,
tison.


tison  于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  于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  于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  wrote:
>>> >
>>> > cc security
>>> >
>>> > Missed in the first place.
>>> >
>>> > Best,
>>> > tison.
>>> >
>>> >
>>> > tison  于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-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>>

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-03 Thread tison 
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  于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  于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  wrote:
>> >
>> > cc security
>> >
>> > Missed in the first place.
>> >
>> > Best,
>> > tison.
>> >
>> >
>> > tison  于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-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-03 Thread tison 
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  于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  wrote:
> >
> > cc security
> >
> > Missed in the first place.
> >
> > Best,
> > tison.
> >
> >
> > tison  于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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-03 Thread Daniel Gruno 

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  wrote:


cc security

Missed in the first place.

Best,
tison.


tison  于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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

2023-07-03 Thread PJ Fanning 
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  wrote:
>
> cc security
>
> Missed in the first place.
>
> Best,
> tison.
>
>
> tison  于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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org