Update build to include PR's in workflows

[csmir]

Testing if this runs build

[KubaZ2]

It's not the best idea I think, because on pull request only activates when the pull request is created, it won't trigger for additional pushes to the source branch.

[csmir]

It is not a bad idea I think, it will rerun the build process every time a new push is made to the pull request. It can even be installed that the PR must succeed build before being able to be merged.

[KubaZ2]

It is not a bad idea I think, it will rerun the build process every time a new push is made to the pull request. It can even be installed that the PR must succeed build before being able to be merged.

You are right, sorry, what do you think about adding types: [opened, synchronize]? That's what is used in https://github.com/NetCordDev/NetCord/blob/alpha/.github/workflows/documentation-preview.yml#L5

[csmir]

You are right, sorry, what do you think about adding types: [opened, synchronize]? That's what is used in https://github.com/NetCordDev/NetCord/blob/alpha/.github/workflows/documentation-preview.yml#L5

The only thing you lose out on in this circumstance is when the PR is reopened. All further logic remains the same. I honestly do not think it is necessary

[KubaZ2]

Not really, there are many activity types:

• assigned
• unassigned
• labeled
• unlabeled
• opened
• edited
• closed
• reopened
• synchronize
• converted_to_draft
• locked
• unlocked
• enqueued
• dequeued
• milestoned
• demilestoned
• ready_for_review
• review_requested
• review_request_removed
• auto_merge_enabled
• auto_merge_disable

Also I think running on reopened is not needed

[csmir]

My bad, I read this:

and thought that was all it was

[KubaZ2]

Well, you are right then, we would only lose reopened there, though I still think reopened is not needed

[KubaZ2]

Thanks!