CI Build Plan on OpenMRS Modules Denies First Time Contributors

After working on a ticket that redirects to resolving a bug, on pushing a commit CI build plan is denied. I have come to learn that First-time contributors on a module need a maintainer to approve running workflows on github.
cc: @dkayiwa @k.joseph @ibacher @mozzy

After reading through @ibacher 's post in respect to first time contributors, all our modules for first time contributors will require approval for Github Actions to deploy their changes to the server. The logic behind this is to help module maintainers combat bad actors, however this has downside for us (and first-time contributors on our modules) automated tests won’t run to provide feedback to the committer that their PR is good (tests passing). Similarly, we won’t be able to tell that whether or new PR is ready for review until those tests are run. A @dev/3+ will need to “touch” each PR request or change to a PR request every time before the tests will run.

As the QA support team is increasing, there might be a need for @k.joseph @christine @grace to do the approvals on such commits to enable the new committers be able to see the test report before reviews are made on such PRs. I was going through the commits from our contributors and found one in such category.

cc: @ibacher @burke @dkayiwa @sharif @jennifer @cintiadr

1 Like

That one should have been approved and i think the contributor will be permitted next time after perhaps a merge. We can handle those first time approvals

1 Like

cc: @k.joseph @sharif

I notice that when the committer makes a change on the approved PR permitted to run Actions still the change requires a touch from the module maintainer to run. This may mean until the committer’s work has been merged into master that the committer’s preceding PRs will then be running github actions. Have observed one of our new contributor when the first PR was approved to run and the second PR on the same module still hugs for Approval
cc: @ibacher @mksd @burke @k.joseph

Yes, this is exactly the behaviour GitHub documented for first-time contributors. See the blog post linked from my initial post.

1 Like