build: add workflow and script to leave comment with make instructions

[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• adds slash command for posting a PR-specific command comment with relevant make command.

Related Issues

Does this pull request have any related issues?

This pull request:

• resolves [RFC]: Add slash command for posting a PR-specific command comment metr-issue-tracker#9.

Questions

Any questions for reviewers of this pull request?

When multiple packages are modified in one PR, the command currently does not leave any comment. Maybe that's not desirable. We could post a generic comment of the relevant commands where the expectation would then be that contributors themselves have to set the relevant environment variables. Thoughts?

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

---

@stdlib-js/reviewers

[kgryte]

the command currently does not leave any comment. Maybe that's not desirable. We could post a generic comment of the relevant commands where the expectation would then be that contributors themselves have to set the relevant environment variables. Thoughts?

Yes, we probably need to leave some sort of comment; otherwise, devs are going to wonder what's wrong and why the command didn't do anything. Devs aren't going to be aware as to why the comment never posts and they may just wait around hoping that one eventually shows up.

[Planeshifter]

@kgryte Now leaving the following comment when multiple packages are changed:

====

Hello! 👋

Pro-tip: This PR changes multiple packages. You can use various make rules with *_FILTERS environment variables to run tests, benchmarks, and examples for specific packages.

For each of the commands, please run them from the root stdlib repository directory (not the package folder!).

You can use pattern matching to target specific packages as follows:

# Run tests for all packages in the math namespace:
make test TESTS_FILTER=".*/@stdlib/math/.*"

# Run benchmarks for specific packages (using OR pattern):
make benchmark BENCHMARKS_FILTER=".*/@stdlib/math/base/special/sin/.*|.*/@stdlib/math/base/special/cos/.*"

Changed Packages

• @stdlib/math/base/special/tan
• @stdlib/math/base/special/tand
• @stdlib/math/base/special/tanh

Documentation Links

• make rules for running examples
• make rules for running project unit tests
• make rules for running benchmarks

[Planeshifter]

/stdlib rebase

[kgryte]

@Planeshifter Is there a reason you keep force pushing to branches? This ends up messing with people's (i.e., my) local copies of your PRs.

[kgryte]

Also, s/*_FILTERS/*_FILTER. The filter environment variables don't end with an S.

[kgryte]

As an additional point, your OR example can be simplified:

make benchmark BENCHMARKS_FILTER=".*/@stdlib/math/base/special/(sin|cos)/.*"

[Planeshifter]

@kgryte I accidentally pushed a commit to this PR that was supposed to go to develop and is unrelated to this PR. I meant to fix this via a force push, but somehow the commands I would usually do to accomplish this (i.e., git reset HEAD~1 --hard followed by git push origin philipp/package-make-commands-comment --force) didn't work. There is definitely something strange going on with our git commit hashes; potentially due to the pre-commit hooks? We should look into this; similar to @rreusser, I have recently encountered some strange behavior with pushes and pulls.

[kgryte]

Yeah, we may need to abandon appending commit meta data to commits.

[Planeshifter]

@kgryte Only the pre-push report does invoke git commit --amend. My hunch is that's the root of the problem because when we amend a commit, we are essentially creating a new commit with a different hash. The pre-push results seem less important than the pre-commit ones, so maybe we could consider disabling these to start with?

[kgryte]

Yeah that is fine. Both are proxy for whether a dev has setup their local env. Feel free to change. I am still down and out.