PECL package should from GitHub Action Artifacts (tag only). After the CI I will upload it to PECL website and send release note to PECL developers list

The pecl support is ready, the documents change will be added in next PRs.

No artifacts output?

What artifacts?

https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts

I just add tests, artifacts should be generate for tag event?

Yes, following tag event.

Add tag event in future?

Can also

What do we discuss here? Do you try to build nightly build or build per commit?

What do we discuss here? Do you try to build nightly build or build per commit?

I prefer to build artifacts from CI by tag event, no nightly build.

The issue would be how should we call that. The RC binary should be built and signed by release manager manually, that is ASF release policy.

The issue would be how should we call that. The RC binary should be built and signed by release manager manually, that is ASF release policy.

Yes, maybe it's not necessary to build artifacts by tag event, or only build the package, not the sign. The signed and later operations must be handle manually.

The issue would be how should we call that. The RC binary should be built and signed by release manager manually, that is ASF release policy.

Yes, maybe it's not necessary to build artifacts by tag event, or only build the package, not the sign. The signed and later operations must be handle manually.

This is not very good practice. Maybe acceptable only? Because you should only sign a thing built manually rather than from a 3rd party. Such as one day, if GitHub mixed some things as CI is not a hard-protected env(or may be hacked), then we signed and released a totally unexpected binary.

The issue would be how should we call that. The RC binary should be built and signed by release manager manually, that is ASF release policy.

Yes, maybe it's not necessary to build artifacts by tag event, or only build the package, not the sign. The signed and later operations must be handle manually.

This is not very good practice. Maybe acceptable only? Because you should only sign a thing built manually rather than from a 3rd party. Such as one day, if GitHub mixed some things as CI is not a hard-protected env(or may be hacked), then we signed and released a totally unexpected binary.

Alright, we will not build artifacts from CI. @heyanlong

I can see you update the scripts, but I can't find the release doc, compiling doc, and pecl install doc udpate.

I can see you update the scripts, but I can't find the release doc, compiling doc, and pecl install doc udpate.

I want to update the doc next PRs.

BTW, you should try to set up the required CI tasks to block merging before CI passed.

BTW, you should try to set up the required CI tasks to block merging before CI passed.

OK, I have some doubts about this. I'll study it later.