search

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 2 months ago

Whenever this is completed we should also:

Ndiritu commented 3 weeks 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 weeks ago

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

baywet commented 3 weeks 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?

Ndiritu commented 2 weeks ago

Yes, create a mono-repo. We could keep the current repos for the core libraries for to re-use the current Packagist webhook configs. I will confirm all details once I run a PoC within the week.

baywet commented 2 weeks ago

Thanks! The two things I'd want us to get clarity on before we make any decision are:

Ndiritu commented 4 days ago

Is there a chance that the "packages from the monorepo" could appear in packagist by mistake? that people could take a dependency on them?

No. We will not be deploying from the mono-repo and we do not need to set up the Packagist GitHub hook/app on the mono-repo. We can tag and do a release on GitHub with a CHANGELOG to track changes but these won't get to Packagist without the config described.

Would "deleting" the existing repos be a breaking change to people who already have a reference to the packages on packagist? (I'm fairly confident the answer to this one is yes)

For this to work, we won't be deleting existing repos. We'll retain the various repos and re-use their existing Packagist configurations so that once changes are tagged on the mono-repo, we push the changes of each sub-project to the corresponding existing GitHub repo with a tag that will trigger an update on Packagist.

We could disable issues & PRs to the existing Kiota core PHP repos, dependabot etc and update the README to point customers to the mono-repo.

Ndiritu commented 4 days ago

Here's a sample set-up of the mono-repo with corresponding individual repos for http and abstractions.

Here's a hacky workflow that simulates how release-please could create a tag that is cascaded to the individual repos. Individual repos are tagged & the update to Packagist happens: abstractions, http

The updates will require a fine-grained PAT set up under the Microsoft Graph org with content read/write permissions on the specific Kiota core PHP repos. We'd store this as a secret that the mono-repo's release workflow can access.

Ndiritu commented 4 days ago

If there are no further concerns/questions @baywet, we can create the kiota-php mono-repo & I can start making the changes.

baywet commented 3 days ago

Thank you for the additional information.

I do have some concerns about any solution requiring PATs after the latest security requirements announcements. Additionally, with the forced roll out of policies, we won't be able to sync things without a pull request.

Do you think we could use an application for the sync instead? How much setup is that going to require?