Publish release without running the deployment script

[volodya-lombrozo]

Quite often, I encounter the following problem:

1. I print the command, "rultor release, version x.y.z, title..."
2. Rultor starts the entire deployment pipeline.
3. Towards the end of the deployment pipeline, one of the maven deployment plugins fails, even though the release happened successfully. (I can find release x.y.z in Maven Central.)
4. However, since the plugin in step (3) reported an error, the entire deployment fails, and the new x.y.z version isn't published on GitHub.
5. Consequently, I need to repeat the same command with the new version x.y.z+1, which has exactly the same content as x.y.z.

I see several possible solutions here:

1. an manually publish the release myself, but I believe, as you would agree, it's tedious. Especially if you have many repositories. Moreover, the style of a manually created release will differ significantly.
2. Add one more option to the Rultor "release" command, something like --skip-script.
3. Introduce a new command, "publish release" or something similar. In this case, we will be able to use "rultor publish release," which will skip the script and just publish the GitHub release.

You can find a real case here. As you can see, I have to repeat the "release" command several times to publish the release on GitHub.

[volodya-lombrozo]

@yegor256 Could you take a look, please?

[volodya-lombrozo]

@yegor256 What do you think? I've faced with the same situation again.

[yegor256]

@volodya-lombrozo I don't have a solution. Still thinking about this...

[pnatashap]

I think it can be usefull to have steps not only for merge and release, as Maven and Gradle have several build-in steps, but we can create our own steps.
In java projects for release we typically need:

1. change the version to remove snapshot
2. build packages and send them to maven central
3. create github release
4. create snapshot version

For some reason step 3 can be required only after package publishing (as an example, you need to test another projects, but they really need new version to be available, so you have some web-hooks to run after publishing)

I think it will be good to add possibility:

• create and call custom steps
• add a property with the name of the step to run after success execution

@volodya-lombrozo @yegor256 What do you think?

[volodya-lombrozo]

@pnatashap As I understand it, we can configure all the 'custom steps' as separate commands inside the already existing merge and release steps. Adding new steps might overcomplicate Rultor.

As for webhooks, I don’t know how to integrate them into Rultor and if Rultor even has to check them somehow. Moreover, it seems Maven Central doesn’t have webhooks. At least, I haven’t found them

[volodya-lombrozo]

To be honest, by adding new "steps" and "properties," we are trying to solve a problem that has already been addressed by GitHub Actions. Actually, you can configure all the required scenarios using GitHub Actions. I don’t think Rultor has to move in this direction and become a build or CI/CD system.

Historically, Rultor was developed when GitHub Actions weren’t in production (please, correct me if I’m wrong). So, some features seem redundant to me at this point in time.

Now, I see (and use) Rultor as a bot for GitHub - which can run simple scripts (like version changing), merging branches, and publishing releases (not deploying).

For example, to solve the original problem in the jtcop project. I disconnected Rultor from the deployment process and configured deployment as the separate GitHub Action. So, Rultor just "publishes" an always successful release, which triggers deployment from GitHub Action.