grafana / grafana-github-actions

Github automation

Github action commands for automating issue management.

Based on work from: https://github.com/microsoft/vscode-github-triage-actions

Commands

Type: label

• action: defines what action to perform (close or addToProject)
• name: defines which label to match on
• addToProject - an object that is required when the action is addToProject and is optional otherwise.
• addToProject.url: Absolute url of the project, the project id will be parsed.
• addToProject.column: Column name to add the issues to, required for old type of projects
• removeFromProject - an object that is required when the action is removeFromProject and is optional otherwise.
• removeFromProject.url: Absolute url of the project, the project id will be parsed.

Note: When removed, the issue will irreversibly loose the project-specific metadata assigned to it. removeFromProject doesn't current work for old type of projects.

Syntax:

{
  "type": "label",
  "name": "plugins",
  "action": "addToProject",
  "addToProject": {
    "url": "https://github.com/orgs/grafana/projects/76",
    "column": "To Do"
  }
}

PR Checks

Mark commits with an error, failure, pending, or success state, which is then reflected in pull requests involving those commits.

Syntax:

[
  {
    "type": "<check>"
    // check specific properties
  }
]

Milestone Check

This will check if a milestone is set on a pull request or not. All properties below except type is optional.

Syntax:

{
  "type": "check-milestone",
  "title": "Milestone Check",
  "targetUrl": "https://something",
  "success": "Milestone set",
  "failure": "Milestone not set"
}

Label Check

This will check if labels.matches matches any labels on a pull request.

• If matches, it will create a success status with labels.exists message.
• If it doesn't match it will create a failure status with labels.notExists message.

If skip.matches is specified it will check if any of the labels exists on a pull request and if so, it will create a success status with skip.message message. This will happen before considering returning a failure status according to above,

All properties below except type and labels.matches is optional. The labels.matches and skip.matches supports providing a * (star) at the end to denote only matching the beginning of a label.

{
  "type": "check-label",
  "title": "New Label Backport Check",
  "labels": {
    "exists": "Backport enabled",
    "notExists": "Backport decision needed",
    "matches": [
      "backport v*"
    ]
  },
  "skip": {
    "message": "Backport skipped",
    "matches": [
      "backport",
      "no-backport"
    ]
  },
  "targetUrl": "https://github.com/grafana/grafana/blob/main/contribute/merge-pull-request.md#should-the-pull-request-be-backported"
}

Changelog Check

This check will enforce that an active decision of including a change in changelog/release notes needs to be taken for every pull request.

This check uses the Label Check and it's detailed description is applicable to this check config as well.

If the result of the Label Check is success status with labels.exists message the check will continue to validate the PR title:

• If the PR title formatting is not valid, e.g. <Area>: <Summary>, it will create a failure status explaining that PR title formatting is invalid.

If the PR title is valid it will continue to validate the PR body. If you use breakingChangeLabels it will check if any of the labels exists on a pull request and if so, it will verify that a breaking change notice section has been added to the PR body:

• If there's no breaking change notice section it will create a failure status explaining that PR lacks a breaking change notice.

{
  "type": "check-changelog",
  "title": "Changelog Check",
  "labels": {
    "exists": "Changelog enabled",
    "notExists": "Changelog decision needed",
    "matches": [
      "add to changelog"
    ]
  },
  "breakingChangeLabels": [
    "breaking-change"
  ],
  "skip": {
    "message": "Changelog skipped",
    "matches": [
      "no-changelog"
    ]
  },
  "targetUrl": "https://github.com/grafana/grafana/blob/main/contribute/merge-pull-request.md#include-in-changelog-and-release-notes"
}

grafana-github-actions's Issues

PR Checks: Status sometimes overridden by action started before another action

Status sometimes overridden by action started before another action resulting in status showing as "failed" even though it should be "successful".

Example:
Pull request opened action triggered below run and checking the timestamps it got the check result Milestone not set at Tue, 08 Feb 2022 08:22:21 GMT:
https://github.com/grafana/grafana-enterprise/runs/5105886551?check_suite_focus=true

Pull request milestoned action triggered below run and checking the timestamps it got the check result Milestone set at Tue, 08 Feb 2022 08:22:20 GMT:
https://github.com/grafana/grafana-enterprise/runs/5105886663?check_suite_focus=true

Automated labeling of external pull requests

What would you like to be added:
Automatic labeling (customized) if pull request author is member or not member of an organization.

Why is this needed:
We have a label in the Grafana repo named pr/external. We manually add this today on pull requests opened by contributors not members of the grafana organization. This allow to filter out pull requests that are opened by external contributors plus some other label like area/frontend or area/backend.

Additional information:
Metadata permission is needed for the token used by the bot to be able to check organization membership for a user.

Add an issue to a project when a milestone is assigned

I wanted to create an automated workflow in some repositories I'm working on so an issue gets added to a new Beta Project whenever it's assigned to a milestone (no matter which one). I found this repository and I think the Commands functionality could be extended so it provides the behaviour I'm looking for in a reusable way.

I started looking into the code and the path seemed straightforward. Adding the onMilestoned handler and in the Commands.ts file ensuring that the match method would let my case go through and end up executing the addToProject action in the perform method.

Also for the command format I was thinking on something like this:

{
  "type": "milestone",
  "action": "addToProject",
  "addToProject": {
    "url": "https://github.com/orgs/grafana/projects/76",
    "column": "To Do"
  }
}

Then I realised that there is some logic that basically prevents certain actions to be performed if there is not a label based interaction. For example, before executing the addToProject command in the perform method there is the following check:

if (
    command.action === 'addToProject' &&
    command.addToProject &&
    command.addToProject.url &&
    issue.labels.includes(command.name)
    ) {
        const projectId = getProjectIdFromUrl(command.addToProject.url)
         ....
    }

The issue.labels.includes(command.name) portion of the conditional would make my case fail as no label actions will be involved. Actually I think that logic must be in the matches logic not in the perform method so we can keep the command validation in one place.

So before jumping into a PR I wanted to double check that I'm not missing anything or maybe what I'm trying to accomplish does not make sense.

Thanks!

Update changelog github action needs to update _index.md with the url to latest version

Adding changelog to index.md sometimes does not work

Sometimes running update changelog actions does not include a link to the changelog in the index file.

Did not work here: https://github.com/grafana/grafana/pull/45540/files
Worked:

• https://github.com/grafana/grafana/pull/45606/files
• https://github.com/grafana/grafana/pull/44822/files

The logic for adding it, is located here

New action that can Auto label PRs from external contributors (no write access)

PR checks needs to subscribe to ready for review

grafana/grafana#43519 introduced skipping draft PR's. However; ready for review action is not handled for the PR checks below:

grafana-github-actions/pr-checks/checks/MilestoneCheck.ts

Line 21 in ead73cc

s.on(['pull_request', 'pull_request_target'], ['opened', 'synchronize'], async (ctx) => {

grafana-github-actions/pr-checks/checks/BackportCheck.ts

Line 31 in ead73cc

s.on(['pull_request', 'pull_request_target'], ['labeled', 'unlabeled'], async (ctx) => {

Bump version action should use another format for the generated branch name

When the branch name starts with a "v" the oss-build-release-branch drone pipeline is triggered.

When bumping the version the branch name is generated as version-bump-<version>. As could be seen in this PR it triggers 2 drone builds. continuous-integration/drone/push is triggered incorrectly due to branch name starts with a "v".

Suggested to change the generated branch name to bump-version-<version>.

addToProject action broken

The current graph query in the getProject function seems to be unsupported now with the following error:
- Field 'projectNext' doesn't exist on type 'Organization'

Enforce PR's to have a milestone assigned before merge is allowed

When label a PR with add to changelog should validate that PR has a milestone assigned.
If not, grot should comment and explain a milestone needs to be added. Maybe should automatically assign a milestone somehow?

Or maybe we should add a label saying to not add it to the changelog instead to enforce most of the things is added to changelog and if not wanted need to add a label to change that?

When label a PR to be backported should validate that PR has a milestone assigned

When label a PR to be backported should validate that PR has a milestone assigned. Grot should comment and explain this.
Not sure how to re-trigger backport though if this happens. Maybe remove the backport label if there's no milestone?

Generating changelog results in two different changelogs comparing changelog and release notes

Compare changelog.md and release-notes.md in grafana/grafana#38968 and notice that the changelog.md is lacking the "Bug: Return empty plugins.DataTimeSeriesSlice when the frame field vector is empty and does not contain any data.".

Changelog-Check: Allow version prefixes

With the merge of #148 we should now also allow for backport titles to include the version prefix (e.g. [v10.0.x] Section: Title).

Github action for signing plugins

Is there any gitHub action created for signing plugins ?

If not it would be really great to have it.

Update to use Node20

GitHub is requesting that actions are transitioned to use Node20: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

When closing a PR without merge (remove the milestone)

Doesn't make sense to have closed PRs in a milestone

Deprecated update-changelog action

Deprecate the update-changelog action in this repository once the new on in grafana-github-actions-go is active (grafana/grafana#66723)

Automatically remove issue from project

We currently have an action to automatically remove an issue from a project when a label is added. It'd be useful to also have the opposite action: remove the issue from a project when a particular (e.g squad label) is removed.

This would be valuable for escalations, that are sometimes assigned to a squad that in the end is not responsible/ owner.

• add action to remove from new project (beta)
• add action to remove from old project

Should create GitHub release as a pre-release when releasing a non-stable/beta version

The github-release action should mark a GitHub release as a pre-release if the version is a non-stable/beta version.

This is important for any external tools/bots relying on the GitHub's "latest" version. "latest" should always point to the latest stable release.

Support command/action for automatically assigning GitHub project to issue/PR

Why:
More and more teams are using GitHub projects in their day-to-day work and currently it's a completely manual task to assign GitHub projects to issues/PRs. Could simplify a lot of things if issue/PR could be automatically assigned to GitHub project based on certain label assigned for example.

Example usage:
Based on the existing issue commands and PR commands in the Grafana repository something like the following would be nice:

Org project:
Based on certain label assigned add issue/PR to project.

{
    "type": "label",
    "name": "area/backend",
    "action": "addToProject",
    "addToProject": {
        "url": "https://github.com/orgs/grafana/projects/27",
        "column": "To do"
    }
}

Repository project:
Based on certain label assigned add issue/PR to project.

{
    "type": "label",
    "name": "area/backend",
    "action": "addToProject",
    "addToProject": {
        "url": "https://github.com/grafana/grafana/projects/15",
        "column": "Inbox"
    }
}

More information:
GitHub rest api in regards to projects seems very limited/hard to use to achieve this task. But seems like the graphql api might be easier to at least figure out the input parameters needed to add/move an issue/PR to a GitHub project. The project below are using the rest api and seems to do a lot of request to figure things out.

Some inspiration from https://github.com/marketplace/actions/automate-projects and https://github.com/takanabe/github-actions-automate-projects

Backport: Set milestone on automated backport

The backport-failed instructions already include a recommendation for setting the milestone according to the target branch. See #150.

We should also do that automatically inside the backport GHA.

Improve error message when `release-note-appender` failed to create PR

When release-note-appender action fails to create automatic PR, it shows error which is not that helpful.

Example:
grafana/loki#10281 (comment)

The process '/usr/bin/git' failed with exit code 1

Would be great to have more details on why it failed.

Context

This error was faced when add-to-release-notes label was removed and added second time (first GH action failed due to rate limits)

Improve breaking changes/deprecation formatting

It's quite hard to overview all of the breaking changes, e.g. v9.0.0-beta2 release notes.

Suggesting a formatting like this:

#### <PR title> (#<PR number/link>)
<!-- breaking change notice -->

Would create something like below using some of the breaking changes from v9.0.0-beta2 release notes as an example:

---

Breaking changes

AuthProxy: Remove deprecated ldap_sync_ttl setting (#49902)

Drop support for deprecated setting ldap_sync_ttl under [auth.proxy]
Only sync_ttl will work from now on

UI/Card: Remove deprecated props (#49885)

Removes support for deprecated heading and description props. Moving forward, the Card.Heading and Card.Description components should be used.

UI/Button: Remove deprecated "link" variant (#49843)

Removes the deprecated link variant from the Button component.
To migrate, replace any usage of variant="link" with fill="text".

Toolkit: Bump dependencies (#47826)

Plugins using custom Webpack configs could potentially break due to the changes between webpack@4 and webpack@5. Please refer to the official migration guide for assistance.

Webpack 5 does not include polyfills for node.js core modules by default (e.g. buffer, stream, os). This can result in failed builds for plugins. If polyfills are required it is recommended to create a custom webpack config in the root of the plugin repo and add the required fallbacks:

// webpack.config.js

module.exports.getWebpackConfig = (config, options) => ({
  ...config,
  resolve: {
    ...config.resolve,
    fallback: {
      os: require.resolve('os-browserify/browser'),
      stream: require.resolve('stream-browserify'),
      timers: require.resolve('timers-browserify'),
    },
  },
});

Please refer to the webpack build error messages or the official migration guide for assistance with fallbacks.

BackendSrv: Throw an error when fetching an invalid JSON #47493

We have changed the internals of backendSrv.fetch() to throw an error when the response is an incorrect JSON.

// PREVIOUSLY: this was returning with an empty object {} - in case the response is an invalid JSON
return await getBackendSrv().post(`${API_ROOT}/${id}/install`);

// AFTER THIS CHANGE: the following will throw an error - in case the response is an invalid JSON
return await getBackendSrv().post(`${API_ROOT}/${id}/install`);

When is the response handled as JSON?

• If the response has the "Content-Type: application/json" header, OR
• If the backendSrv options (BackendSrvRequest) specify the response as JSON: { responseType: 'json' }

How does it work after this change?

• In case it is recognised as a JSON response and the response is empty, it returns an empty object {}
• In case it is recognised as a JSON response and it has formatting errors, it throws an error

How to migrate?
Make sure to handle possible errors on the callsite where using backendSrv.fetch() (or any other backendSrv methods).

Update yarn.lock file fails sometimes

It seems like the bump version github action is not working sometimes.
Worked:

• https://github.com/grafana/grafana/pull/43889/files (was me doing some testing)

Did not work:

• https://github.com/grafana/grafana/pull/45168/commits
• https://github.com/grafana/grafana/pull/45529/commits
• https://github.com/grafana/grafana/pull/45603/commits

The code can be found here

Bump version action should re-generate the yarn.lock file

When releasing 8.3.0-beta1 and 8.3.0-beta2 we had to manually run yarn to re-generate the yarn.lock file and commit it, see commit and PR.

If we run yarn when bumping version for older Grafana versions, like v8.2.6/v8.2.x branch - would that cause any harm?

Update changelog: pull-request title-markdown should emphasize the ":" too

when we have a pull-request title like: "Explore: Fix the thing", this gets markdownified as "**Explore**: Fix the thing".

based on discussion with @oddlittlebird, this should change to "**Explore:** Fix the thing".

basically, the colon at the end of the first segment of the title should go inside the emphasized section.

for the original discussion see grafana/grafana#32760

Backport: Copy all labels and description

When creating a backport the whole description and all the labels should be copied over alongside the current note linking back to the original PR.

PR checks: Don't create status for draft PR

Think it doesn't make sense to create PR Check status for draft PR's.

update changelog: escape underscore characters

we had pull-requests with _ characters in the title, for example handle $__interval. the changelog-generator should markdown-escape the _, but it is not doing that currently.

Set milestone on version bump PRs

The PR should be assigned the milestone of the version (Same name)