release workflow not autotriggering on release

[opoudjis]

Have had to manually release. Had to do so two weeks ago as well.

[opoudjis]

Also metanorma-iso

[CAMOBAP]

The previous release (2.7.1) failed because of a test failure: https://github.com/metanorma/metanorma-standoc/actions/runs/7015710661

The current release 2.7.2 passed but failed because the release already was done manually https://github.com/metanorma/metanorma-standoc/actions/runs/7158427172/job/19490497506#step:11:22

To be on the same page, the release initiated only once tests passed

[opoudjis]

This is a change I do not welcome whatsoever.

There is a massive wait after the metanorma-cli push, where I have to wait for 4 hours until the job is done, but after months of tuning the release, I've accepted that I can go to bed Monday nights after 2-3 hours of working on releases, knowing that I don't even have to monitor docker any more, just the metanorma-cli log.

Now you tell me that I have to wait between isodoc, metanorma-standoc, and metanorma-iso releases as well, until the gems depending on them will be released.

metanorma-standoc depends on isodoc directly. metanorma-iso depends on both directly. All other flavours depend on both directly, and four flavours depend on metanorma-iso; another four depend on metanorma-generic directly.

This is going to introduce at least a 15 minute wait between each of isodoc, metanorma-standoc, metanorma-iso, and metanorma-generic, during which time I cannot usefully do anything else. In a release workflow that is already taking much too long, with much too few agents, and for tests that I'm going to look at in the dashboard and remedy anyway. Moreover, GHA routinely falls over for things that are not genuine issues anyway, such as poor installation of gems and random timeouts.

This was done despite me saying that I need the releases to be immediate, repeatedly, over the past year.

I am not going to accept this. In fact, I am going to actively sabotage it, by manually releasing gems when I need them. And if that is not going to be acceptable to you, then you can start debugging and releasing the gems yourself.

[CAMOBAP]

сс @ronaldtse

[opoudjis]

Additional problem: if I do detect a problem in GHA, and fix it with another push, and that problem is specifically about just the rspec files being obsolete (such as refreshing VCR cassettes, which happens all the time), I have to either trigger a manual release afterwards anyway, or issue a brand new release just because the test files were out of date. That's what I'm faced with right now with metanorma-itu at https://github.com/metanorma/metanorma-itu/actions/runs/7158474076 and https://github.com/metanorma/metanorma-itu/actions/runs/7158682014

I take back "at least a 15 minute wait between each of isodoc, metanorma-standoc, metanorma-iso, and metanorma-generic". metanorma-standoc on rspec has taken 25 minutes to run. And until metanorma-standoc gem is available, I cannot release metanorma-iso or any other flavour and expect its tests to use the latest gem. Which absolutely means half an hour that I cannot do any releases in. Yes, I can test the other gems, but I still need to trigger a release to make things happen, and if I wait until the end, that is adding even more time to the release process.

This is security theatre, without any appreciation of how the release process works. It is the equivalent of a password policy resulting in everyone writing passwords down on sticky notes, because they cannot possibly remember them. All the needed testing and gatekeeping is already happening on GHA at metanorma-cli. If you insist on this step, I will simply stop issuing releases. I have too much to do already without the release time ballooning out from 3 hours to 5.