microsoft / kiota-abstractions-php

PHP abstractions for Kiota generated API clients
https://aka.ms/kiota/docs
MIT License
5 stars 1 forks source link

Group Kiota PHP repositories #156

Open andrueastman opened 4 months ago

andrueastman commented 4 months ago

Related to https://github.com/microsoft/kiota/issues/4636 and https://github.com/microsoft/kiota-abstractions-dotnet/issues/238

As a language specific concern, we should look into the feasibility of grouping the repos and outline if this is not feasible in this issue.

baywet commented 1 month ago

Whenever this is completed we should also:

Ndiritu commented 3 days ago

(Subject to future edits as investigation continues, but edits will be listed here)

Composer (dependency manager) supports linking between sub-projects, however Packagist (dependency repository) doesn't support deployments from sub-packages. Packagist expects a package to be hosted within a GitHub repository whose root folder contains a composer.json file. Reference

Currently, package deployment works like this, our PHP repos have a Packagist GitHub app set up & a webhook that triggers publishing to Packagist when a tag is created. The version of the packages is determined by the tag or adding a "version" property to the composer.json.

With a mono-repo, our limitation would be in the deployment process.

Various tools exist that split the mono-repo into repositories during deployment & pushes commits & tags to the new repos so that deployment happens.

Two major tools seem viable for this:

Mono-repo builder

which provides various CLI utilities to validate our dependency versions across sub-projects & release automations which we shouldn't need courtesy of release-please. It does the repo split using a release workflow with the monorepo-split-github-action & providing it with repo:write permissions to split the repository and publish. Mono-repo builder has ~3M+ installs & seems stable at v11.x

Splitsh-lite

which does only the repo subtree split and has been used by Google Cloud PHP mono-repo to deploy their various service libraries as separate packages ref. They augment this with their own custom scripts.

Mono-repo builder seems most viable however it still leaves us potentially with our individual repositories for abstractions, http etc but we can manage everything via a kiota-php repository.

Pending:

Ndiritu commented 3 days ago

Open to further feedback here @andrueastman, @baywet, @shemogumbe

baywet commented 15 hours ago

Thank you for the additional information.

So if I'm following things properly, in those scenarios we'd:

Or am I missing anything here?