dessant / label-actions Goto Github PK

It would be nice to support closing issues as not planned vs completed. It might be even the default.

This tools is amazing and is exactly what I have been wishing for. I'm able to get this workflow to work for labeled issues but I havent figured out how to trigger an action from an unlabeled issue. For example, I tried the following but it does not get triggered when an unlabeled issue is created:

unlabeled:
  # Post a comment
  comment: >
    This is an unlabeled issue post.

My workflow file does have triggers on labeled or unlabeled issues:

on:
  issues:
    types: [labeled, unlabeled]
  pull_request:
    types: [labeled, unlabeled]
  discussion:
    types: [labeled, unlabeled]

If this is explained somewhere in the documentation, I apologize for missing it. If not, perhaps you could add an example of triggering on an unlabeled issue as well. Thanks for maintaining such a useful tool!

In addition to the close/lock/open actions, it would be nice to have add/remove additional labels actions when an issue/pr is labeled/unlabeled.

Would you accept a PR for this?

I think it will be great feature to fire a github action based on labels.

Thanks!

Feature suggestion

Support commenting on labeled discussions.
GitHub now allows maintainers to add label(s) to a discussion in the same way as an issue.

The action currently only supports issue or pull request types.

It would be very nice if the action can comment on discussion type as well.

Why this would be nice to have?

As a triagist on the renovatebot/renovate repository I frequently apply certain labels to let contributors know we need something from them, either formatting logs properly, making a minimal reproduction etc.
We now frequently convert a issue to a discussion, but sometimes we still need something from the contributor in the discussion.

It would be very very nice if we could use the labels on discussions the same way as on issues. This way the maintainers can use the standard templates, instead of typing out a response manually every time.

Are you willing to work on this?

I cannot offer help making this feature. If this is too much work, or outside the scope of what you want the action to do, feel free to close the issue. 😉

The documentation states that close-reason is optional:

However this is only partially true, since if not provided and close is true, the workflow will fail with the following error:

Error: GraphqlResponseError: Request failed due to following response errors:
 - Variable $reason of type DiscussionCloseReason was provided invalid value

I suggest to update the documentation with something like the following:

-Optional, defaults to ''
+Optional when `close` is set to `false`, defaults to ''

It would be great if this action would be able to assign or unassign milestones based on labels added or removed so that issues and prs could be directly assigned/unassigned to milestones and not just closed/opened.

Hello, what I am trying to accomplish is that all of my issues that are flagged with pending are changed to merged when a push is made to the main branch. This way my Q/A testers are able to see when the changes have gone live on our beta server.

Is this possible to accomplish?

Hi!

Label Actions has been rewritten for GitHub Actions, offering new features and better control over your automation presets. The legacy GitHub App has been deprecated, and the public instance of the app has been shut down. You're receiving this message because the deprecated app is still installed for your user account or organization.

You can follow the user guide and examples to install the new action for your repositories:

https://github.com/dessant/label-actions

If you need any help with configuring the action, please open an issue or message me at [email protected].

The continued development of Label Actions is made possible thanks to the support of awesome backers. If you'd like to join them, please check out https://github.com/sponsors/dessant

Please ignore the new permission request for the app, it was only used to notify project maintainers directly, without opening thousands of issues.

Thanks,
Armin Sebastian

Hello,

Would be nice to have a docker image so I can try it directly in my k8s cluster.

Could you add a feature to convert issues to discussions when a specific label is added?

Something like this maybe.

invalid:support:
  comment: >
    :wave: @{issue-author}, we use the issue tracker exclusively for bug reports.
    However, this issue appears to be a support request. The issue has been moved to a discussion.
    Thanks.
  discussion_convert: true
  discussion_category: Support

Do i need to add a label for every commit in the PR? It seems that when i trigger the workflow based on a label, it doesn't trigger for the next commit, unless it is added again

While Unlocking an issue with adding a label goes in a loop

unlocks -> locks again -> unlocks

my yml files look like this

lock-unlock.yml under .github/workflows/

name: 'lock/unlock issues'

on:
  issues:
    types: labeled

permissions:
  issues: write


jobs:
  action:
    runs-on: ubuntu-latest
    steps:
      - uses: dessant/label-actions@v3
        with:
          process-only : 'issues'
          config-path : '.github/lock-unlock.yml'

lock-unlock.yml under .github/

'🚦 status: awaiting triage':
  issues:
      comment: >
          some random
      lock : true

'🏁 status: ready for dev':
  issues:
      comment: >
            The thread has been temporarily unlocked.Please follow our community guidelines.
      unlock : true

##ScreenShots

is there any functionality which will run the CI only for PRs that have no label added to them, the unlabeled trigger runs only when a label is removed from the PR

What do I have to make in order for the bot to make proper line-breaks?

Right now I have set this text here in the label-actions.yml as a response for the Problem: Need more info label:
https://github.com/Andre601/PurrBot/blob/master/.github/label-actions.yml#L27-L35

But it seems like that the bot completely ignores new lines and just puts everything in a single line.
Here's the response in a test-issue:
purrbot-site/PurrBot#10 (comment)

I tried it with adding double-spaces in case it's an issue with markdown, but this doesn't fix it.
But empty lines seems the bot to recognize.

Image

Hi!

I wonder what this error means.

Background:

I wanted safe-publish label to be automatically unlabeled when it's labeled.
(Scenario: Human labels PR, and some workflows are run, and then the label is to be removed.)

.github/workflows/main.yaml:

name: main

on:
  pull_request_target:
    types: [labeled] # <-- The workflow is triggered when it's labeled.

jobs:
  main:
    permissions:
      contents: write 
      issues: write
      pull-requests: write 

    runs-on: ubuntu-latest

    steps:

      # - name: do something..... (Omitted for brevity)

      - name: unlabel # <-- I want to remove the label from the PR
        if: contains(github.event.pull_request.labels.*.name, 'safe-publish')
        uses: dessant/label-actions@v4
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

.github/label-actions.yml:

'safe-publish':
  prs:
    unlabel:
      - 'safe-publish'

https://docs.github.com/en/graphql/reference/mutations#closediscussion

https://docs.github.com/en/graphql/reference/mutations#reopendiscussion

Lovely tool!

One thing that would be nice is to be able to specify additional filter conditions to omit actions/comments under certain conditions.

E.g. (syntax is just a sample)

issues:
  actions:
    enhancement:

      # Only comment with a funding request if it the funded label has not yet been set
      if: !funded

      comment: >
        This has been accepted as an enhancement request. Good job :+1:
        [Learn how to make it happen](https://make.it.happen/fundmenow).

Hi,

Thank you for creating and maintaining this action. I am opening a feature request because I think it would be very useful to manage labels from all repositories in an organization by allowing the configuration file to be centralized (or maybe I am just not seeing something, and it is already possible).

I've tried the action for a single repository, and it works awesome. Then, I wanted to set this action at an organizational level (in the special type .github repository - not folder - ) and reuse it across many repositories to define the (massive) configuration file only once. Today, the configuration is not declared inline in the same workflow but in a configurable external file. However, the external configuration file is always assumed to live inside the repository whose job is calling the action. While I can centralize the action with an on.workflow_call it seems I cannot centralize its configuration.

I understand that I can copy and paste the configuration file across all my organization repositories, but I thought that if the configuration file could be loaded externally or, more simply, defined inline in the same workflow YML, it would be very useful to reuse it everywhere.

I understand there is no way to specify a remote configuration file, so this feature request would allow this:

On a shared repository that contains all label actions defined, like https://github.com/orgname/.github:

# file git/orgname/.github/.github/workflows/label-actions.yml
name: 'Label Actions'
on:
  workflow_call:
...
jobs:
  action:
    runs-on: ubuntu-latest
    steps:
      - uses: dessant/label-actions@v4
        with:
          # resolve against an external repo
          config-path: https://github.com/orgname/.github/.github/label-actions.yml@main

And then all repos wanting to use this action would simply call it like this:

name: 'Label Actions'
on:
  issues:
    types: [labeled, unlabeled]

permissions:
  contents: read
  issues: write

jobs:
  labels:
    uses: orgname/.github/.github/workflows/label-actions.yml@main

Would that make sense?

Did you consider to sync labels between issues and linked pull requests? Do you see it as an advantage? Is it doable?

As a developer
I would appreciate to have possibility to automatically copy particular labels from an issue to a pull request
So that I don't need to manually copy them once a pull request is created.

The big picture is that we're using HayStack to measure our KPIs and they have an approach that bases on pull requests.