Skip to content

chore(main): release 0.2.0 - #13

Merged
NickJosevski merged 2 commits into
mainfrom
release-please--branches--main
Aug 28, 2026
Merged

chore(main): release 0.2.0#13
NickJosevski merged 2 commits into
mainfrom
release-please--branches--main

Conversation

@team-modern-deployments-bot

@team-modern-deployments-bot team-modern-deployments-bot commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

🤖 I have created a release beep boop

0.2.0 (2026-08-28)

⚠ BREAKING CHANGES

  • api_key now takes the API key itself rather than the name of an environment variable to eval. what_if, packages_folder and package_prerelease are rejected, because the octopus CLI has no equivalent and silently ignoring them would change what a build does. config_file, log_level, timeout, proxy, proxy_username, proxy_password and ignore_ssl_errors warn and are ignored. OCTOPUS_CLI_SERVER and OCTOPUS_CLI_API_KEY are no longer read.

Features

  • migrate from the retired octo CLI to the octopus CLI (a6688fe)

Bug Fixes

  • correct version references in migration notes (1dc2191)

This PR was generated with Release Please. See documentation.

NickJosevski added a commit that referenced this pull request Aug 22, 2026
Releasing 1.0.0 (#13) is blocked by a failing Lint check, and the cause is
this workflow, not the release.

The sed used `.*` after `create-release#`, which also consumed the trailing
colon of the YAML mapping key:

  - OctopusDeploy/create-release#v0.1.1:   ->   - OctopusDeploy/create-release#v1.0.0

Every example then had an unkeyed sequence entry followed by indented
mappings, so the plugin linter fails with "bad indentation of a sequence
entry". The bug has been here since the workflow was added; it simply never
ran, because there has been no release since 2022.

The replacement matches only the version and always re-emits the colon, so
it is also self-healing on a README a previous run already mangled. It
still leaves other plugins' refs (e.g. octopus-login#) alone.

Also adds a concurrency group. release-please pushed to the release branch
three times in quick succession, and the three resulting runs raced on git
push; one failed with "! [rejected] ... (fetch first)".

Verified by running the new sed over main's README and linting the result:
7 examples valid, no YAML errors.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@NickJosevski
NickJosevski force-pushed the release-please--branches--main branch from eaa7cf1 to b9cfaa6 Compare August 22, 2026 02:07
NickJosevski added a commit that referenced this pull request Aug 26, 2026
Releasing 1.0.0 (#13) is blocked by a failing Lint check, and the cause is
this workflow, not the release.

The sed used `.*` after `create-release#`, which also consumed the trailing
colon of the YAML mapping key:

  - OctopusDeploy/create-release#v0.1.1:   ->   - OctopusDeploy/create-release#v1.0.0

Every example then had an unkeyed sequence entry followed by indented
mappings, so the plugin linter fails with "bad indentation of a sequence
entry". The bug has been here since the workflow was added; it simply never
ran, because there has been no release since 2022.

The replacement matches only the version and always re-emits the colon, so
it is also self-healing on a README a previous run already mangled. It
still leaves other plugins' refs (e.g. octopus-login#) alone.

Also adds a concurrency group. release-please pushed to the release branch
three times in quick succession, and the three resulting runs raced on git
push; one failed with "! [rejected] ... (fetch first)".

Verified by running the new sed over main's README and linting the result:
7 examples valid, no YAML errors.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@team-modern-deployments-bot team-modern-deployments-bot changed the title chore(main): release 1.0.0 chore(main): release 0.2.0 Aug 26, 2026
NickJosevski added a commit that referenced this pull request Aug 26, 2026
release-please opened #13 proposing 1.0.0, because bump-minor-pre-major
defaults to false and a breaking change therefore takes 0.x straight to
1.0.0. We want to keep iterating on 0.x, so set it to true: pre-1.0.0
breaking changes now produce a minor bump, making the octo -> octopus
migration 0.2.0 rather than 1.0.0.

Also corrects the version numbers the migration docs promise, which were
written assuming a 1.0.0 release: "changed in v1" -> "changed in 0.2.0",
and "Migrating from v0.x" -> "Migrating from 0.1.x" with its anchor.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@NickJosevski
NickJosevski merged commit 067154c into main Aug 28, 2026
5 checks passed
@NickJosevski
NickJosevski deleted the release-please--branches--main branch August 28, 2026 07:01
@github-actions

Copy link
Copy Markdown
Contributor

🤖 Created releases:

🌻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants