[I] PHP SDK: wire release pipeline [iggy]

["countradooku (via GitHub)" <gi...@apache.org>]

countradooku opened a new issue, #3304:
URL: https://github.com/apache/iggy/issues/3304

   Follow-up from the experimental PHP SDK review.
   
   The PHP SDK currently has pre-merge coverage, but it is not wired into the release/post-merge publishing path. Track the release pipeline work in one place before enabling PHP SDK publication.
   
   ## Missing pieces
   
   - Add `sdk-php` to `.github/config/publish.yml` / `.github/workflows/publish.yml` so the publish workflow can select and run PHP SDK publishing.
   - Add a PECL `package.xml` if PECL distribution is part of the PHP SDK release path.
   - Add `.github/actions/php/post-merge/action.yml` for PHP SDK post-merge publishing/tagging behavior.
   - Include `sdk-php` in the SDK loop in `.github/workflows/post-merge.yml` around the existing SDK auto-publish detection block near line 100.
   
   ## Notes
   
   A combined ticket is intentional: these pieces should be designed together so PHP release behavior matches the other SDKs and does not get forgotten after the initial experimental cut.
   
   Related: #3302
   Initial PHP SDK work: #3235
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] PHP SDK: wire release pipeline [iggy]

["hubcio (via GitHub)" <gi...@apache.org>]

hubcio commented on issue #3304:
URL: https://github.com/apache/iggy/issues/3304#issuecomment-4547641806

   I spent some time reading our existing python release wiring to PyPI + the pie/asf docs. notes below.
   
   on publish.yml - the config entry alone won't be enough. something like:
   
   ```yaml
   sdk-php:
     tag_pattern: "^php-sdk-([0-9]+\\.[0-9]+\\.[0-9]+(?:-[0-9A-Za-z.-]+)?(?:\\+[0-9A-Za-z.-]+)?)$"
     registry: packagist
     version_file: "foreign/php/composer.json"
     version_regex: '"version"\s*:\s*"([^"]+)"'
   ```
   
   is needed, but to mirror the python path we also need: `packagist: 'php'` in the `toType` map at `publish.yml:337`, `'php'` added to the sdk allowlist at line 330, `php` appended to the `publish_other` input description at line 52, a new `has_php` plan output + a `build-php-extensions` reusable workflow gated on it (same shape as `has_python` / `build-python-wheels` at line 702), both `publish-docker` and `publish` job `needs:` lists extended to include it (lines 734 and 1041), a `matrix.type == 'php'` step invoking the new post-merge action, `PACKAGIST_TOKEN` added to the job env at line 1054, a `wait-for-url` gate polling `repo.packagist.org/p2/apache/iggy-php.json` analog to pypi/npm at line ~1215, and `sdk-php` in the sdk loop at `post-merge.yml:100`. composer.json has no `version` field today - we either add it or treat the git tag as source of truth, but the regex above only works with the field.
   
   on the build matrix - fun fact, php 8.3 and 8.4 share `ZEND_MODULE_API_NO = 20230901` so one `.so` loads in both, building separate-per-minor is conservative but not strictly required for that pair. realistic v0.1 is php {8.3, 8.4} × os {linux-gnu, linux-musl, macos} × arch {x86_64, aarch64}, NTS only = 12 artifacts. ZTS and windows can wait until someone asks. plus an sdist-equivalent source tarball (pie falls back to source build if no prebuilt resolves), and a third-party license manifest via `cargo-about` matching what `_build_python_wheels.yml` does for the same rust dep tree.
   
   cross-compile is the actual sharp edge here. ext-php-rs uses bindgen against host php headers and has no documented cross path - stock `cross` won't work without custom docker images carrying per-arch php-dev + libclang. easier path is native arm64 runners (now free on public github repos) and macos arm64 runners.
   
   artifact naming has to match pie's `pre-packaged-binary` template exactly or it won't resolve:
   
   ```
   php_{ExtensionName}-{Version}_php{PhpVersion}-{Arch}-{OS}-{Libc}-{Debug}-{TSMode}.{Format}
   ```
   
   `{TSMode}` is literal `nts`/`zts` (omittable), `{Libc}` is `glibc`/`musl`/`bsdlibc`, `{Format}` is `zip` or `tgz`. so for example `php_iggy_php-0.1.0_php8.4-x86_64-linux-glibc-nts.zip`. `{ExtensionName}` must match the `#[php_module]` name in `lib.rs`. each archive needs `LICENSE` + `NOTICE` alongside the `.so` - asf policy applies to convenience binaries too.
   
   on the asf side, the canonical release is a signed source tarball on `dist.apache.org/repos/dist/dev/iggy/`, [VOTE] thread on dev@ for at least 72h with 3 binding +1s, then promotion to `release/iggy/`. packagist + github releases are downstream convenience binaries and MUST carry the same version as the source tarball. claiming the `apache/iggy-php` packagist namespace needs an asf infra request - `apache/*` packages already exist on packagist so the path is established, pmc will know the exact channel.
   
   edge/pre-release support comes for free and is simpler than python's. composer semver and cargo semver use the same `-dev1` / `-rc1` / `-beta1` suffix, so `composer.json` and `foreign/php/Cargo.toml` hold the identical version string (no translator script like the python pyproject.toml `.dev1` ↔ Cargo `-dev1` bridge). composer auto-detects stability from the suffix, the existing `extract-version.sh --is-pre-release` gate at `post-merge.yml:100` picks it up unchanged.
   
   couple of small things: skip pecl, pie covers the modern install flow. add a `scripts/ci/php-sdk-version-sync.sh` analog to the python one, wired into `extract-version.sh --check`, asserting `composer.json` ↔ `foreign/php/Cargo.toml` ↔ git tag all agree before publish.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@iggy.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org