Formatting the text in the body #247
Labels
question
A question on how to use this action
Comments
|
You can use Markdown formatting in the body: github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: "**Bold text here**"
})Note that if you have a multi-line comment that the indentation must be correct, otherwise your formatted text will be placed github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: `# Images
# Title
`
}) |
|
Cheers @josh- I'll give this a spin. This really ought to be in the documentation |
|
Works like a charm! Cheers :) |
|
You're welcome! Just opened #252 adding an example to the docs 👍 |
Indeed, my issue was a wrong indentation 👍 |
|
@josh- We denote code or a command within a sentence using single backticks. Could you please explain how to escape backticks when they're part of the text body? |
|
@amol-patel you should be able to use a
|
|
Thank you so much @joshmgross |
eskultety
added a commit
to eskultety/hermeto
that referenced
this issue
Dec 9, 2024
This workflow is a direct consequence of the asynchronous release schedule of pydantic and pydantic core and the fact that pydantic is always pinned to a particular pydantic-core version. Dependabot doesn't see these transitive relations and so can't properly update the versions in this case (it always assumes the latest for every dependency). This will naturally lead to broken CI making these version updates impossible to merge. Since our project directly only cares about pydantic and not pydantic-core, we can ignore pydantic-core updates (future patch) and run a dedicated workflow on every dependabot pull request that would check whether changes to our requirements files are needed. If changes are needed, the GitHub actions bot will comment on the pull request that a change to these files are needed and provide a patch to the reviewer to apply and update the pull request. The workflow is only executed when changes to the requirements files are proposed (realistically only by dependabot). Note that it's not possible to specify the source branch as the workflow trigger, only the target branch, and so that could not have been used as a better filter for dependabot-proposed pull requests specifically. It is run using a Python Alpine docker image, saves the git diff produced by pip-compile to the default github actions environment followed by a github script action that will pop the diff out of the environment and use it to comment on the pull request. References: - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#multiline-strings - https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/using-conditions-to-control-job-execution - https://github.com/actions/github-script?tab=readme-ov-file#comment-on-an-issue - actions/github-script#247 (comment) - actions/github-script#220 (comment) Signed-off-by: Erik Skultety <eskultet@redhat.com>
eskultety
added a commit
to eskultety/hermeto
that referenced
this issue
Jan 3, 2025
This workflow is a direct consequence of the asynchronous release schedule of pydantic and pydantic core and the fact that pydantic is always pinned to a particular pydantic-core version. Dependabot doesn't see these transitive relations and so can't properly update the versions in this case (it always assumes the latest for every dependency). This will naturally lead to broken CI making these version updates impossible to merge. Since our project directly only cares about pydantic and not pydantic-core, we can ignore pydantic-core updates (future patch) and run a dedicated workflow on every dependabot pull request that would check whether any additional changes (i.e. transitive dependency version locks) to our requirements files are needed. If so, then the GitHub actions bot will comment on the pull request that a change to these files is needed and will provide a patch to the reviewer to apply and update the pull request. The workflow is only executed when changes to the requirements files are proposed (realistically only by dependabot). Note that it's not possible to specify the source branch as the workflow trigger, only the target branch, and so that could not have been used as a better filter for dependabot-proposed pull requests specifically. It is run using a Python Alpine docker image, saves the git diff produced by pip-compile to the default github actions environment followed by a github script action that will pop the diff out of the environment and use it to comment on the pull request. References: - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#multiline-strings - https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/using-conditions-to-control-job-execution - https://github.com/actions/github-script?tab=readme-ov-file#comment-on-an-issue - actions/github-script#247 (comment) - actions/github-script#220 (comment) Signed-off-by: Erik Skultety <eskultet@redhat.com>
github-merge-queue bot
pushed a commit
to hermetoproject/hermeto
that referenced
this issue
Jan 6, 2025
This workflow is a direct consequence of the asynchronous release schedule of pydantic and pydantic core and the fact that pydantic is always pinned to a particular pydantic-core version. Dependabot doesn't see these transitive relations and so can't properly update the versions in this case (it always assumes the latest for every dependency). This will naturally lead to broken CI making these version updates impossible to merge. Since our project directly only cares about pydantic and not pydantic-core, we can ignore pydantic-core updates (future patch) and run a dedicated workflow on every dependabot pull request that would check whether any additional changes (i.e. transitive dependency version locks) to our requirements files are needed. If so, then the GitHub actions bot will comment on the pull request that a change to these files is needed and will provide a patch to the reviewer to apply and update the pull request. The workflow is only executed when changes to the requirements files are proposed (realistically only by dependabot). Note that it's not possible to specify the source branch as the workflow trigger, only the target branch, and so that could not have been used as a better filter for dependabot-proposed pull requests specifically. It is run using a Python Alpine docker image, saves the git diff produced by pip-compile to the default github actions environment followed by a github script action that will pop the diff out of the environment and use it to comment on the pull request. References: - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#multiline-strings - https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/using-conditions-to-control-job-execution - https://github.com/actions/github-script?tab=readme-ov-file#comment-on-an-issue - actions/github-script#247 (comment) - actions/github-script#220 (comment) Signed-off-by: Erik Skultety <eskultet@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey folks! Awesome project you have here!
Just have a question regarding the
bodyproperty when creating a comment.Is it possible to format it? I.e. make it bold or apply some colour to the text?
This may be in the documentation, but I have not come across it.
Many thanks!
The text was updated successfully, but these errors were encountered: