CI (GitHub Actions)

[esensar]

Hello 👋

I have been an active (paid) contributor to SimpleMobileTools for a couple of months last year and I believe that not having any kind of automated checks (and no automatic formatting) caused unnecessary friction. PRs were often sitting for quite some time, only for the sole maintainer to notice some minor formatting issue or something like that and then waiting for more time for the PR creator to fix it.

I also believe it would help new contributors be more confident that their solution is not breaking some of the rules of the project. I would gladly take this up and set it up for all of the applications if it sounds like a good idea.

[naveensingh]

@esensar Hey, that sounds like a good idea. PRs are welcome :)

[naveensingh]

I guess I'll merge it now then. I'll investigate this later.

[esensar]

I have now added reusable workflows: FossifyOrg/.github#7

There are also templates there, which will make it easier to use these workflows.

[esensar]

By the way, I found an examle of commenting workflow. To get around the permission issue, it is done as a separate workflow, triggered by the completion of PR workflow: https://github.com/bevyengine/bevy/blob/main/.github%2Fworkflows%2Fci-comment-failures.yml

We could maybe consider something similar.

[naveensingh]

That solution looks promising. I tried using pull_request_target instead of pull_request in the image-minimizer here but it doesn't seem to work: https://github.com/FossifyOrg/Messages/actions/runs/7677669075/job/20930629270?pr=53

From this page:

Note that, if the PR comes from a fork, it will have only read permission despite the permissions given in the action for the pull_request event. In this case, you may use the pull_request_target event. With this event, permissions can be given without issue (the difference is that it will execute the action from the target branch and not from the origin PR).

But with these, we need to make sure to never check out untrusted code: https://nathandavison.com/blog/github-actions-and-the-threat-of-malicious-pull-requests

[esensar]

Yeah, we would have to move away from gradle wrapper in that case, since it is a local script that could be rewritten and do whatever on that PR, while having full access. We would have to use that checkout to get code from the PRs branch, which would leave us vulnerable. I think that workflow complete hook is safer.

[naveensingh]

Thanks a lot for the help, closing this now.