fastlane/github-actions

Remove a default `pr-comment` message from `communicate-on-pull-request-merged`

mollyIV opened this issue · 3 comments

Currently there is a default pr-comment message for communicate-on-pull-request-merged Action:

pr-comment:
description: 'A comment to post on a pull request when code changes are merged'
default: "Thank you for your contribution to _fastlane_ and congrats on getting this pull request merged :tada:\n
The code change now lives in the `master` branch, however it wasn't released to [RubyGems](https://rubygems.org/gems/fastlane) yet.\n
We usually ship about once a week, and your PR will be included in the next one.\n\n
Please let us know if this change requires an immediate release by adding a comment here :+1:\n
We'll notify you once we shipped a new release with your changes :rocket:"

The message does not contain congrats for a pull request author. Below you will find an original message:

image

To avoid ambiguity, we should delete a default message from an Action and make it required instead.

The workflow file will look like this then:

name: Processing merged pull requests
on: 
  pull_request:
    types: [closed]

jobs:   
  communicate-on-pr-merged:
    name: Communicate on pr merged
    runs-on: ubuntu-latest    
    steps:
    - uses: actions/checkout@master
      with:
        ref: refs/heads/master
    - uses: fastlane/github-actions/communicate-on-pull-request-merged@latest
      with:
        repo-token: "${{ secrets.BOT_TOKEN }}"
        pr-comment: "Hey @${{ github.event.pull_request.user.login }} :wave:\nThank you for your contribution to _fastlane_ and congrats on..."

Why do we not want to offer the possibility to not use a customized pr-comment? I think having safe defaults make sense, which can totally not use the user name.

Why do we not want to offer the possibility to not use a customized pr-comment?

github-actions repository was created to store fastlane specific GitHub Actions, not indented to use by broader audience. If we wanted to make a reusable GitHub Action, we would need to create a separate repository dedicated to the action itself (versioning support, etc.).

Taking into account the above, having a default message, that we would not use anyway, introduces ambiguity.

Ok, agree.