chore(deps): bump cycjimmy/semantic-release-action from 3 to 4

[dependabot[bot]]

Bumps cycjimmy/semantic-release-action from 3 to 4.

Release notes

Sourced from cycjimmy/semantic-release-action's releases.

v4.0.0

4.0.0 (2023-08-31)

Features

• update node version on runner to 20 (0c20554)

BREAKING CHANGES

• set the default node version to 20

v3.4.2

3.4.2 (2023-03-30)

Bug Fixes

• fix installation error for npm-audit (86a0e59), closes #159

v3.4.1

3.4.1 (2023-03-30)

Bug Fixes

• windUpJob: set last_release outputs before returning (91e3dc6)

v3.4.0

3.4.0 (2023-03-15)

Features

• add ci input parameter (b356b18)

v3.3.0

... (truncated)

Changelog

Sourced from cycjimmy/semantic-release-action's changelog.

4.0.0 (2023-08-31)

Features

• update node version on runner to 20 (0c20554)

BREAKING CHANGES

• set the default node version to 20

3.4.2 (2023-03-30)

Bug Fixes

• fix installation error for npm-audit (86a0e59), closes #159

3.4.1 (2023-03-30)

Bug Fixes

• windUpJob: set last_release outputs before returning (91e3dc6)

3.4.0 (2023-03-15)

Features

• add ci input parameter (b356b18)

3.3.0 (2023-03-07)

Features

• support for option tagFormat (ed38eb0)

3.2.0 (2022-11-04)

Features

• added gitHead and gitTag outputs (385af4f)

3.1.2 (2022-10-19)

... (truncated)

Commits

• 61680d0 chore(release): 4.0.0 [skip ci]
• 31a37a4 Merge pull request #171 from enell/node20
• 81a6335 docs: modify docs for v4
• 3b12aa9 chore: upgrade deps
• 0c20554 feat: update node version on runner to 20
• 7f0c0e4 Merge pull request #165 from elebiodaslingshot/patch-1
• 4dd16d6 docs: fix example tag format with proper lodash
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions[bot]]

Pull request title looks good 👍!

If this pull request gets merged, it will not cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.0.0. This pull request is not a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy! This pull request title should be in this format: ``` : short description of change being made ``` **If your pull request [introduces breaking changes](https://web.archive.org/web/20220725195319/https://nordicapis.com/what-are-breaking-changes-and-how-do-you-avoid-them/)** to the code, use this format: ``` !: short description of breaking change ``` where `` is one of the following: - `feat:` - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project. - `fix:` - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project. - `docs:` - This pull request is making documentation changes, only. - `refactor:` - A change was made that doesn't fix a bug or add a feature. - `test:` - Adds missing tests or fixes broken tests. - `style:` - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc) - `perf:` - Changes improve performance of the code. - `build:` - Changes to the build system (maven, npm, gulp, etc) - `ci:` - Changes to the CI build system (Travis, GitHub Actions, Circle, etc) - `chore:` - Other changes to project that don't modify source code or test files. - `revert:` - Reverts a previous commit that was made. ### Examples: ``` feat: edit profile photo refactor!: remove deprecated v1 endpoints build: update npm dependencies style: run formatter ``` Need more examples? Want to learn more about this format? [Check out the official docs](https://www.conventionalcommits.org/). **Note:** If your pull request does multiple things such as adding a feature _and_ makes changes to the CI server _and_ fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[github-actions[bot]]

Hey, there @dependabot[bot] 👋🤖. I'm a bot here to help you.

⚠️ Pull requests into the branch beta typically only allows changes with the types: fix. From the pull request title, the type of change this pull request is trying to complete is: chore. ⚠️

This pull request might still be allowed to be merged. However, you might want to consider make this pull request merge into a different branch other then beta.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy! This pull request title should be in this format: ``` : short description of change being made ``` **If your pull request [introduces breaking changes](https://web.archive.org/web/20220725195319/https://nordicapis.com/what-are-breaking-changes-and-how-do-you-avoid-them/)** to the code, use this format: ``` !: short description of breaking change ``` where `` is one of the following: - `feat:` - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project. - `fix:` - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project. - `docs:` - This pull request is making documentation changes, only. - `refactor:` - A change was made that doesn't fix a bug or add a feature. - `test:` - Adds missing tests or fixes broken tests. - `style:` - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc) - `perf:` - Changes improve performance of the code. - `build:` - Changes to the build system (maven, npm, gulp, etc) - `ci:` - Changes to the CI build system (Travis, GitHub Actions, Circle, etc) - `chore:` - Other changes to project that don't modify source code or test files. - `revert:` - Reverts a previous commit that was made. ### Examples: ``` feat: edit profile photo refactor!: remove deprecated v1 endpoints build: update npm dependencies style: run formatter ``` Need more examples? Want to learn more about this format? [Check out the official docs](https://www.conventionalcommits.org/). **Note:** If your pull request does multiple things such as adding a feature _and_ makes changes to the CI server _and_ fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[dependabot[bot]]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.