The app doesn't leave a message when the workflow is triggered via comment

[ematipico]

The pkg.pr.new works fine, and the workflow is triggered correctly when using pull_request.

However, when I changed it, it wouldn't leave a comment to the PR anymore. Particularly, I used this trigger event:

on:
  workflow_dispatch:
  issue_comment:
    types: [created] 

The workflow is triggered correctly and pkg.pr.new worked: https://github.com/withastro/astro/actions/runs/10490295437

However the GithHub application didn't leave any comment. Is it expected or a bug?

[Aslemammad]

As you can see here:

pkg.pr.new/packages/backend/server/routes/webhook.post.ts

Lines 74 to 75 in 6ba34b5

	if (prMarkEvents.includes(payload.action)) {
	await pullRequestNumbersBucket.setItem(prDataHash, payload.number);

The github app listens for pull request events! Did you send that PR after installing the app or before installing the app? If it's the latter, then you may want to close and re-open a PR.

Let me know what do you think.

[Aslemammad]

if not, I can debug this and find the root cause.

[ematipico]

I tried to open a new PR for test, and it didn't work as expected.

Test PR: withastro/astro#11807 (you can ignore the comment from the github actions bot)
Workflow correctly triggered: https://github.com/withastro/astro/actions/runs/10492555591/job/29064374704?pr=11807

[ematipico]

The github app listens for pull request events!

I am trying to guess; maybe that's the issue? The workflow was triggered by a comment that was created in a PR. Or maybe I don't know the code enough 😆

[Aslemammad]

Nicee, yea that might be an issue, I'll debug soon! Thank you so much

meanwhile you may want to fallback to publishing on each change? So you won't be blocked by me, let me know what can I do, would be happy to help.

[Aslemammad]

@ematipico What do you think about the vuetifyjs/nuxt-module way? https://github.com/vuetifyjs/nuxt-module/pulls?q=is%3Apr+is%3Aclosed

Maybe you can use their pattern of using comments.

[ematipico]

That wouldn't work for us, because we want to publish multiple previews in the same PR, but we don't want to do it at every commit to not waste CI time.

Is there some kind of limitation?

[Aslemammad]

Hmm, I see, no as far as I see there's no limitation here but I wanted to have you on boarded on a solution meanwhile I look this up!

[Aslemammad]

Ok, after my research, I believe there's a limitation!

Workflows for issue_comments (and related events) do not give info on the pull request, but instead, it assumes the run is on the default branch (main).

That's why as you can see in your workflows, it targets a commit that is in the main history and not in that PR history. And since there's no PR for the main branch, it does not comment anything :)

So not commenting is an expected behavior, and the content of the published packages is not correct too since it comes from the main branch and not the updated PR.

And since pkg.pr.new relies on github events and their information, it cannot do something for this case (it might be able though, but I think that'd require so many hacks) since we get the same info!

What I believe can be done is what you're already doing.

comment -> add a label with `gh` -> run the workflow

But that'd enable next workflows without a comment since the label is there. Maybe you can do this:

comment -> add a label `gh` -> run the workflow -> remove label with `gh`

This would make the continuous releases need a comment for each preview and hopefully achieve the desired behavior.

https://github.com/withastro/astro/blob/11ebf3bd152042dd36ce2af464a07b02e65dd1d2/.github/workflows/preview-release.yml#L58-L60

Adding this to the next step:

- run: |
    gh issue edit ${{ github.event.issue.number }} --remove-label "pr: preview" --repo ${{ github.repository }}
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

And for comments, maybe you can use this option in pkg-pr-new.

Related: #200 by @AriPerkkio since it has the same issue with issue_comment more or less

[AriPerkkio]

Related: #200 by @AriPerkkio since it has the same issue with issue_comment more or less

Yep exactly - issue_comment is not initialized on the same branch that the PR is. The context is for default (main/master) branch.

and the content of the published packages is not correct too since it comes from the main branch and not the updated PR.

In #200 there's a work-around mentioned for this:

# Checkout to the PR branch
- uses: actions/checkout@v4
  with:
    ref: refs/pull/${{ github.event.issue.number }}/head

@Aslemammad I just remembered that I have built a custom Github Action that does exactly this. It listens for comments on PR, then checks out to that branch, runs some code and finally posts results to that PR as comment. Sources are available here: https://github.com/AriPerkkio/eslint-remote-tester-compare-action/blob/master/src/index.ts#L18

[Aslemammad]

In #200 there's a work-around mentioned for this:

That works but it does not affect the events that the github webhook sends us, which is what we rely on!

https://github.com/stackblitz-labs/pkg.pr.new/blob/main/packages/backend/server/routes/webhook.post.ts

Same with the action!

The issues (it's not an issue from Github's side 😅) lies in the fact that we do not get the information we get from pull request events in issue_comment events.

And the information issue_comment gives in a workflow run event in the webhook is all around the default branch.