staffbase / autodev-action Goto Github PK

Summary

On bigger repositories, with many dev'ed PRs in parallel, the status comments of this action link all of them as intended.
However this leads to a GitHub annotating each of the PRs with all the other PRs. This is due to GitHub autolinker recognizing the PR-Links and annotating the linked PR with something like "This PR was mentioned in PR".

Feature Suggestion

The Status Comments are nice and give a good feedback of what the action produced, so disabling the comments is not the optimal Solution here.
We should provide a way to reduce the AutoLink spam without giving away the comments nicities.

Possible Implementation

I was thinking about some kind of templating we can provide for the action. So we can give the Users the ability to Structure the comments themselves.
This is the way for example release-drafter/release-drafter handles dynamic outputs.
So we use some kind of templating Engine (e.g. go-template) and provide the users a documentation of what parameters we compile into the Template. This way they can leave out what they want to leave out, or can even use handmade messages for the Comments ✨ 🎨

Bug Description

When adding the action to a new repository, it fails when there is no "dev" branch yet.

Expected Behavior

The action should just create one. Doesn't matter where IMHO, it's force-pushed anyway.

How to Reproduce

Create a new repo and try to add this action.

Context

n/a

Environment

(in a company-internal repository, please contact via Slack if interested)

Feature Suggestion

• using a library to execute the git commands

Possible Implementation

• found one library as possible implementation
• take a look at some more alternatives

Context

• don't execute the commands bare

Feature Suggestion

Possibility to configure workflows and checks to be successful before merging pull requests to dev-branch

Possible Implementation

Check the PR workflows/checks and get the status of either a pre-configured list of checks and/or all checks which are required for merge. The second option might be easier to configure at the auto dev action, as it would be just a boolean flag, with the downside that e.g. sonarcube also might prevent the "deving".

Context

Currently pull request with a broken CI pipeline are blocking the auto deving flow as also CI on dev branch is breaking. Often you need then to wait for other PRs to be fixed or "un-deved". By only considering PRs with successful CI pipeline, we could prevent this.

Bug Description

Expected Behavior

How to Reproduce

Context

Environment

• Version:
• OS:

Feature Suggestion

• add missing debug loggings to get a better overview if the action fails

Possible Implementation

• there is a good documentation from GitHub with the usage of debug