semantic-release / gitlab

:fox_face: semantic-release plugin to publish a GitLab release
MIT License
278 stars 77 forks source link

Comment on issues resolved by current release #40

Closed joshdcomp closed 2 years ago

joshdcomp commented 6 years ago

This may be on a roadmap but I didn't see any issues related to it so I figured I'd drop one here to at least indicate my support:

Similar to semantic-release/github, it would be awesome if the gitlab package had success/fail plugins to comment on issues related to the current release.


As an aside If I can get buy-in from my manager to work on this I'd be happy to but it's nothing to bank on

pvdlg commented 6 years ago

semantic-release is only aware of the commits included in the release. In order to figure out which Merge Request or issue to comment it needs to:

  1. Parse the content of commit message and look for closing keywords (e.g. Fix #123)
  2. Find the merged Merge Requests that contains any commits from the release
  3. Parse the content of those Merge Requests and look for closing keywords (e.g. Fix #123)

Item 2 and 3 are not possible at the moment because GitLab doesn't offer an API to find the Merge Requests that ended up merging a given commit. See https://gitlab.com/gitlab-org/gitlab/issues/15833.

In the @semantic-release/github plugin this is done with the search issues API that allows to pass a list of commit sha and return PRs associated with those.

joshdcomp commented 6 years ago

Ah ok—is the team opposed to at least exposing notification functionality for item 1? It would be nice to have some method to automate notifying people when we've fixed their issues

pvdlg commented 6 years ago

I'd rather implement all 3 when we have the required API function. It would be quite confusing for users to sometime have a notification (when using Fix #123 in the commit), sometimes not (when using Fix #123 in the Merge Request).

tmeijn commented 3 years ago

Hi, this is a old issue, but I think this should be possible now if I'm thinking this through correctly:

  1. The Commits API now supports finding the associated Merge Request(s) with a commit sha
  2. From there you find ID of the Merge Request that actually has been merged and use that ID to find issues that have been closed by the Merge Request
  3. Post the comment on those issues
  4. Profit?

Hope this helps!

tmeijn commented 3 years ago

I tried to verify the proposal above would work and it seems so! I wrote it in bash for prototyping:

#!/bin/bash

# CONFIGURATION VARIABLES
CI_API_V4_URL="https://gitlab.com/api/v4/"
CI_PROJECT_ID="[PROJECT_ID]"
CI_DEFAULT_BRANCH="main"

post_release_comment() {
  # find all commits that are on the repository default branch and are not merge commits.
  for sha1 in $(git rev-list ${CI_DEFAULT_BRANCH} --no-merges --max-count=10); do
      # Find the nearest tag ahead of the commit. Only useful in this test, this would come from @semantic-release
      release_tag="$(git describe --contains ${sha1} | cut -d'~' -f1 | cut -d'^' -f1)"

      # Use the Commits API to find associated Merge Requests by sha
      # Use JQ to filter on merged MRs (since closed/draft MRs would also be associated) and retrieve the internal ID
      merge_request_id="$(curl -sSL -X GET -g -H "PRIVATE-TOKEN: ${GL_TOKEN}" \
        "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/repository/commits/${sha1}/merge_requests" | jq -r '.[] | select(.state == "merged") | .iid')"

      echo "DEBUG: For commit ${sha1}, found MR ID: ${merge_request_id}"

      # If no associated MR is found, exit current iteration
      if [ -z "${merge_request_id}" ]; then continue; fi

      # Next, find all issues associated with the MR using the Merge Requests API
      issue_ids="$(curl -sSL -X GET -g -H "PRIVATE-TOKEN: ${GL_TOKEN}" \
        "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests/${merge_request_id}/closes_issues" | jq -r '.[] | select(.state == "closed") | .iid')"

      # If no associated issue(s) are found, exit current iteration
      if [ -z "${issue_ids}" ]; then continue; fi

      echo "DEBUG: For Merge Request ID ${merge_request_id}, found Issue IDs: ${issue_ids}"

      # For all found issues, post a comment (Note in Gitlab terms) to that issue
      for issue_id in ${issue_ids[@]}; do
        # The Comment
        echo -e ":tada: This issue has been resolved in version ${release_tag} :tada:\n\nThe release is available on [Gitlab Release](../../releases/${release_tag})" >note.md

        # finally, encode and post comment to Notes API
        curl -sSL -X POST -g -H "PRIVATE-TOKEN: ${GL_TOKEN}" \
          --data-urlencode body@note.md \
          "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/issues/${issue_id}/notes"
      done
  done
}

post_release_comment

and the result running on a small project:

image

nfriend commented 3 years ago

@tyronedd Very cool! Thanks for putting this proof-of-concept together 💯

github-actions[bot] commented 2 years ago

:tada: This issue has been resolved in version 7.1.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

github-actions[bot] commented 2 years ago

:tada: This issue has been resolved in version 7.2.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

github-actions[bot] commented 2 years ago

:tada: This issue has been resolved in version 8.0.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: