php published to archived sub repo.

[mpkorstanje]

@mattwynne unlike cucumber-expressions and tag-expressions this project publishes to a sub repo.

messages/.github/workflows/release-go.yml

Lines 7 to 21 in b89d404

	jobs:
	publish-go-subrepo:
	name: Publish to cucumber/messgaes-go subrepo
	runs-on: ubuntu-latest
	environment: Release
	permissions:
	contents: write
	steps:
	- uses: actions/checkout@v3
	with:
	fetch-depth: '0'
	- uses: cucumber/action-publish-subrepo@v1.1.0
	with:
	working-directory: go
	github-token: ${{ secrets.CUKEBOT_GITHUB_TOKEN }}

And while https://github.com/cucumber/messages-go does exist, I've archived it because it wasn't getting updated. I suppose that pushing to a sub repo is in error?

[mpkorstanje]

Looks intentional to me. Resolved by unarchiving the repository's for go and php.

@mattwynne what about cucumber-expressions and tag-expressions?

[mpkorstanje]

We currently publish a subtree of the go directory to https://github.com/cucumber/messages-go, is this still nessesary?

I'm not sure, I think github.com/cucumber/messages-go was planned for deprecation (and maybe archiving), originally with the >idea of replacing it with monorepo, now with this repo. So probably any automations/maintenance for messages-go could be >disabled.

Originally posted by @vearutop in #101 (comment)

This means that:

• We can archive messages-go, gherkin-go
• We can remove the release-go workflows for:
  • cucumber-expressions
  • tag-expressions
  • messages
  • gherkin

The release-github action and tags should be sufficient.

[mattwynne]

I've discussed this with @mpkorstanje today. We've decided that:

• For Go, we'll stop using subrepo publishing
• For Go, we'll stop creating special tags (e.g. https://github.com/cucumber/tag-expressions/blob/main/.github/workflows/release-go.yml#L24)

For PHP, I'd like a final say-so from @ciaranmcnulty about the way forward. We're currently inconsistent - this repo is publishing to a https://github.com/cucumber/messages-php subrepo on release, but would it be OK to just use the main polyglot repo as we've decided to do for Go?

[mpkorstanje]

This now also breaks on builds that are tagged with go/vVersion: https://github.com/cucumber/gherkin/actions/runs/3788087513/jobs/6440509357

[ciaranmcnulty]

Now we've broken up the monorepo we certainly could publish from the polyglot repos (previously we could not have published multiple PHP packages from a single repo).

There are a few factors against it, so it depends how they stack up against the neatness benefits:

1. Bigger package size. Composer downloads a package either by doing git clone on the repo, or by downloading the .tar.gz from a tagged release. Either way there isn't a good mechanism to trim out the non-PHP stuff. This is more of a concern than maybe some of the other langs because the thing we distribute is the source repo, not some JAR-type thing.
2. For discoverability reasons composer.json needs to be in the root of the repository, which means a PHP concern would escape from its subfolder.
3. I kinda like that we can treat the sub repo copy as a publish action. Without that there's no distinction between publishing and tagging (which might not be an issue).

My weak preference is to keep the sub repo(s) unless there's a good technical reason to not have them. We could have that in a separate org if the main driver is 'less in the cucumber org'?

If there are technical reasons to do it the other way it's probably fine too :)

[mpkorstanje]

While I would love to publish from a single repo, I do consider the location of the composer.json a definite blocker.

And while I'd like to reduce the number of moving parts involved, the primary goal is to reduce the variation between different repos.

For example, based on this information, we can conclude that that the PHP implementations of Cucumber expressions and tag expressions effectively aren't published.

I'll split those problems into their own issues.

Cheers.

[ciaranmcnulty]

@mpkorstanje there are only PHP implementations of messages and gherkin currently

[mpkorstanje]

That simplifies things. Just the issue of pushing tags to a sub repo then. 😄

[mpkorstanje]

Tag issue was fixed by manually deleting the go tag. I think that may be been a bit of junk.