I think we would want these split commits to still run through CI to make sure the independent library is still fully independent and can pass tests on its own.

We can upload patches to Gerrit that have a CR+2 applied immediately (what libup also does) so once the patch is uploaded, it goes through CI and is then merged. If it fails CI, abandon, go back to Wikibase.git, fix and retry again? That part seems a little meh.

In T258396#6321883, @Legoktm wrote:

I think we would want these split commits to still run through CI to make sure the independent library is still fully independent and can pass tests on its own.

We can upload patches to Gerrit that have a CR+2 applied immediately (what libup also does) so once the patch is uploaded, it goes through CI and is then merged. If it fails CI, abandon, go back to Wikibase.git, fix and retry again? That part seems a little meh.

I was thinking CI can run composer multiple times and separately for each package to make sure tests pass on their own too (e.g. they don't depend on something that's not mentioned in their dependencies). I assume it would work similar to what's happening with npm packages in repo (like tainted-ref and wikidata bridge). Do you think it wouldn't work?

I think that's fine as a start but it's still possible to leak outside of the library accidentally (e.g. require '../SomeClass.php';) and pass tests. For complete confidence the split repo is usable standalone, the tests should be runnable and pass in that split repo itself.

Yeah, that's true

Change 618777 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[mediawiki/extensions/Wikibase@master] Add github action to publish changes library

https://gerrit.wikimedia.org/r/618777

The action needs to be merged first: see https://github.com/wmde/git-filter-repo-docker-action/pull/1

Quick summary of what I remember seeming to discuss the last two days as a team before I forget:

• We'll start with a github action because it means we can move quicker and don't need to search for the resources for someone who can set up jenkins / zuul jobs for us
• SSH was easier than github OAuth tokens and allows us to avoid needed a "machine account"
• We used a docker action rather than python on the "host runner" because it allowed more customisation e.g. python and git version
• We put the action under WMDE github org as it's not intrinsically tied to wikibase and could be used in other places
• We put the actual extracted repo under Wikimedia because the code is derived from Wikibase.git
• We (I) boldly made this repo
• If we need to then the same docker container could probably be redeployed on jenkins/zuul

Change 618777 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Add github action to publish changes library

https://gerrit.wikimedia.org/r/618777

Change 618966 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[mediawiki/extensions/Wikibase@master] Force git-filter-repo to run

https://gerrit.wikimedia.org/r/618966

Change 618966 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Force git-filter-repo to run

https://gerrit.wikimedia.org/r/618966

This is mostly working now – you can see the first successful run and the resulting GitHub repository.

Leaving open for verification so we can check the next build – since we don’t do a force push, the next build should only succeed if the git-filter-repo produces consistent commit hashes. In my tests that always worked, but let’s see if it works here too.