ci: manual rerelease trigger

[justlevine]

This PR adds the option to manually trigger a rerelease for old versions. This is useful for when the generator itself changes (i.e. a PR to the repo like #3 ).

This is handled by appending a +repack.{#} to the tag, and then deleting the old tag since we want to match the WPGraphQL versions, but SemVer doesnt give build meta and precedence.

As such, users who already have the package locally may need to install with --no-cache to get the repack, but this is IMO still better than only having fixes to the repo apply to future WPGraphQL stubs, when a major use case is using the stubfile to test minimum version compatibility.

[justlevine]

@szepeviktor if you have a minute, Id love your thoughts on this 🙏

[szepeviktor]

I am generally afraid of errors. I would do a rerelease manually, or rather not change existing tags.

[szepeviktor]

Automating fixing errors is popular. I do error prevention.

[szepeviktor]

Healthy packages do not need stubs #2 This is very nice and sustainable: composer require wp-graphql/wp-graphql

[justlevine]

I am generally afraid of errors. I would do a rerelease manually,

The way it's set up, a rerelease will only happen from a manual workflow trigger when the should_rerelease input is set to true. 🚀

or rather not change existing tags.

I agree generally. The specific problem here is that we can't safely append a point-version to the release number, but if the old tag exists, Composer doesnt know how to differentiate between {$version} and {$version+{$meta} which means there's no way to guarantee composer will pull the newest build.

I think that the fact that it needs to be manually triggered provides a decent enough guardrail (along with the fact that changing the actual generator should be a fairly rare occurrence).

[szepeviktor]

If you go through the stubs file once there is no need to rerelease ever again. Here are the namespaces.

      1 namespace Appsero {
      1 namespace Composer\Autoload {
      2 namespace GraphQL {
      1 namespace GraphQLRelay {
      1 namespace GraphQLRelay\Connection {
      1 namespace GraphQLRelay\Mutation {
      1 namespace GraphQLRelay\Node {
      1 namespace GraphQLRelay\Tests\Connection {
      1 namespace GraphQLRelay\Tests\Mutation {
      1 namespace GraphQLRelay\Tests\Node {
      1 namespace GraphQLRelay\tests {
      1 namespace GraphQLRelay\tests\Node {
      1 namespace GraphQL\Error {
      1 namespace GraphQL\Exception {
      2 namespace GraphQL\Executor {
      2 namespace GraphQL\Executor\Promise {
      2 namespace GraphQL\Executor\Promise\Adapter {
      1 namespace GraphQL\Experimental\Executor {
      1 namespace GraphQL\Language {
      1 namespace GraphQL\Language\AST {
      2 namespace GraphQL\Server {
      2 namespace GraphQL\Type {
      7 namespace GraphQL\Type\Definition {
      1 namespace GraphQL\Type\Validation {
      1 namespace GraphQL\Utils {
      2 namespace GraphQL\Validator {
      2 namespace GraphQL\Validator\Rules {
      4 namespace WPGraphQL {
      1 namespace WPGraphQL\Admin {
      1 namespace WPGraphQL\Admin\GraphiQL {
      1 namespace WPGraphQL\Admin\Settings {
      6 namespace WPGraphQL\Connection {
      3 namespace WPGraphQL\Data {
      1 namespace WPGraphQL\Data\Connection {
      1 namespace WPGraphQL\Data\Cursor {
      1 namespace WPGraphQL\Data\Loader {
      1 namespace WPGraphQL\Model {
      1 namespace WPGraphQL\Mutation {
      1 namespace WPGraphQL\Registry {
      1 namespace WPGraphQL\Registry\Utils {
      1 namespace WPGraphQL\Server {
      1 namespace WPGraphQL\Server\ValidationRules {
      7 namespace WPGraphQL\Type {
      6 namespace WPGraphQL\Type\Connection {
      1 namespace WPGraphQL\Type\Enum {
      1 namespace WPGraphQL\Type\Input {
      1 namespace WPGraphQL\Type\InterfaceType {
      1 namespace WPGraphQL\Type\ObjectType {
      1 namespace WPGraphQL\Type\Union {
      1 namespace WPGraphQL\Utils {
      5 namespace {

[justlevine]

If you go through the stubs file once there is no need to rerelease ever again.

Not sure I trust that optimism in myself 😂. The merges on this repo (and wordpress-stubs where sadly improvements like php-stubs/wordpress-stubs#97 are only applied to future releases) are good examples.

There are also a lot of things in WPGraphQL core (quick egs: untyped array keys, stubbed properties on WordPress core classes) that these stub-files could benefit from adding (either until they're addressed in the plugin or to apply on older releases) and are on my long-term to-do list.

[szepeviktor]

All right Mr. Time Traveler!

[szepeviktor]

Branch not deleted here 🎈

[szepeviktor]

namespace Appsero is not in the stubs file any more.

[justlevine]

namespace Appsero is not in the stubs file any more.

Yeah, thats because v1.4.7 isnt actually available on packagist despite being listed (🤷), so the rebuild stopped there. #11 address this, the dry run is passing, so this should be fixed live momentarily.

[szepeviktor]

Now I see why you added this rerelease workflow.