17.1.1

Description

Abstract

This Pull Request addresses issues that arise when using GitHub Actions with pull requests from forked repositories.
Additionally, it introduces improvements to the release workflow.

Background

When handling pull requests from forked repositories using GitHub Actions, certain features and permissions are restricted due to security concerns.
As a result, PRs like #1647 could not be merged directly and required employees to duplicate and merge the changes manually.

Details

To resolve the issue, two main approaches were implemented:

Using the pull_request_target Event

By leveraging the pull_request_target event, GitHub Actions can now run with the permissions of the base repository, even for pull requests originating from forks.
This approach is only safe when workflows do not execute code from the forked repository directly, which is ensured in this PR.

Changing the pull_request Event to push

In the Release.yaml workflow, which handles release creation after a pull request is merged, the trigger has been changed from the pull_request event to the push event.
This means the workflow now runs on pushes to the master branch, rather than being triggered only by PR merges into master.

Additionally, pre-merge validation of release creation is now possible without relying on secrets.
This is achieved by using 8BitJonny/gh-get-current-pr to retrieve pull request information linked to a merge commit.

Using the release event for updating Docker images

Previously, Docker.yaml is called by Release.yaml with version code.
By this PR, Docker.yaml will be called by publishing Release (usually caused by Release.yaml).
In addition, I use catkin_package_version for constructing tags of Docker images.

Destructive Changes

Merge Queue is NOT recommended

When using a Merge Queue, the pull_request event is triggered once per PR, while the push event may not be triggered the same number of times.
If fewer push events occur than expected, the bump logic might not execute as intended.
For this reason, Merge Queue is not recommended.

Example:
If a bump major PR and a bump patch PR are merged by merge queue, the bump major might be skipped.

Known Limitations

Unnecessary Execution of Release.yaml

Since the Release.yaml workflow pushes to the master branch, it ends up triggering itself again.
However, during this second execution, no associated pull request can be detected, so no new release will be created.