Split workflow into multiple commands

[jooola]

Currently, only a single run command is exposed to the users, and process the entire logic to prepare and publish a release.

This command could be split into multiple commands, each responsible for a specific part of the workflow. The goal is to give the users more control of what they want to accomplish, making the tool really flexible to many use cases. This design may be inspired by git and the 2 command families: plumbing and porcelain. Going as deep as exposing plumbing command might not be necessary, but this illustrate the design idea.

The role of the run command will only chain each sub commands and tie everything together.

This provides a solid base to build on top, as each sub command may be improved by adding any kind of flags, without having to jam every options in the run command.

Each sub command will define a context in which they may be run, for example analyzing the unreleased commits does not require a filesystem, everything is fetched from the forge.

This new architecture will allow users to split their workflow and add their own advanced customization if needed (referring to #160) (I still believe a hook to e.g. a user provided script could be really powerful).

Another future improvement building on top of this new architecture, is to be able to extract parts of the workflow in a Github App/Gitlab Webhook integration, that can listen on PR/MR events and run the analyze commit step without having to rely on the project CI/CD pipelines. A changelog may be generated on each event, if further step in the workflow may be skipped if no changes were detected.

Below are a 1 schema that tried to describe the existing architecture, and 2 ideas of future architecture. Those schema could still be improved.

The [[text]] boxes represent steps that need to be run against a filesystem/git repository/in CI.

---

---

[apricote]

I like the idea to split the commands up into "porcelain" and "plumbing".

I already tried to split up the logic a bit, with 3 "phases" at the moment: Onboarding, CreatePendingReleases and ReconcileReleasePR. Your graphs focus on ReconcileReleasePR, which is certainly the largest.

releaser-pleaser/releaserpleaser.go

Lines 58 to 75 in 9801884

	func (rp *ReleaserPleaser) Run(ctx context.Context) error {
	err := rp.runOnboarding(ctx)
	if err != nil {
	return fmt.Errorf("failed to onboard repository: %w", err)
	}
	err = rp.runCreatePendingReleases(ctx)
	if err != nil {
	return fmt.Errorf("failed to create pending releases: %w", err)
	}
	err = rp.runReconcileReleasePRWithRetries(ctx)
	if err != nil {
	return fmt.Errorf("failed to reconcile release pull request: %w", err)
	}
	return nil
	}

I would be happy to accept a PR that splits up runReconcileReleasePR into smaller parts and exposes them as their own CLI subcommands. We would also need to think about how the data (analyze info / release info) is saved and passed from stage to stage.