CommentReleasedIssues

What it does

CommentReleasedIssues uses prepared release context to comment on issues linked from the release’s changeset and review metadata.

It is a post-publication communication step, not a planning step.

Why use it

Use CommentReleasedIssues when you want monochange to close the loop after publication by posting structured release follow-up comments.

This is especially valuable when:

• issues are part of the public release workflow
• you want issue comments to stay tied to the exact prepared release data
• you want a dry-run preview before touching hosted issue state

Inputs

• format — text or json

Step-level when condition

All CLI steps support an optional when = "..." condition.

If the expression resolves to false at runtime, monochange skips the step and continues with the next step.

when = "{{ inputs.enabled }}"

Step-level always_run flag

All CLI steps support an optional always_run = true flag.

When set, the step executes even if a previous step in the same command has failed. This is useful for cleanup, notification, or dry-run preview steps that must run regardless of earlier outcomes.

always_run = true

Prerequisites

• a previous PrepareRelease step in the same command
• [source].provider = "github"

Side effects and outputs

• builds issue comment plans from prepared release context
• in dry-run mode, previews which issues would be touched
• in normal mode, creates or skips comments based on provider state

Example

[cli.publish-and-comment]
help_text = "Publish a release and comment on linked issues"

[[cli.publish-and-comment.inputs]]
name = "format"
type = "choice"
choices = ["text", "json"]
default = "text"

[[cli.publish-and-comment.steps]]
type = "PrepareRelease"
inputs = ["format"]

[[cli.publish-and-comment.steps]]
type = "PublishRelease"
inputs = ["format"]

[[cli.publish-and-comment.steps]]
type = "CommentReleasedIssues"

Composition ideas

Publish first, then comment

The most common and most sensible sequence is:

1. PrepareRelease
2. PublishRelease
3. CommentReleasedIssues

That ordering reflects the real-world intent: only comment after the release event exists.

Comment and then run a reporting step

[cli.publish-comment-report]
help_text = "Publish a release, comment on issues, and print a short report"

[[cli.publish-comment-report.steps]]
type = "PrepareRelease"

[[cli.publish-comment-report.steps]]
type = "PublishRelease"

[[cli.publish-comment-report.steps]]
type = "CommentReleasedIssues"

[[cli.publish-comment-report.steps]]
type = "Command"
command = "echo issue comments processed for {{ release.version }}"
shell = true

Why choose it over a custom GitHub API script?

Because the built-in step already consumes monochange’s linked issue and review metadata model. A shell script would need to rediscover which issues matter for the release.

Common mistake

Using CommentReleasedIssues without a GitHub source configuration. This step is intentionally provider-specific today.