Automating syncing with GitHub Actions (Final Testing going on for Java Track, Open to More Tracks)

Exercism
41

Yeah, it’d for sure be a separate discussion per track, and I’d note it’s not just unmaintained repos that may need a deep dive. I recently did this for Common Lisp and Emacs Lisp, both of which are maintained. For those, you’d want maintainer buy-in beforehand, but it hasn’t been too controversial so far.

1 Like
42

I was surprised to see this run in a fork. Will everyone with a fork get this failed run?

https://github.com/BNAndras/exercism-coffeescript/actions/runs/1628069102

Edit - I got notifications for several forks so the answer is yes.

1 Like
43

I also have an error 403 for Run Configlet Sync · exercism/pyret@f332dd7 · GitHub. I suspect this may be due to rate-limiting if the GHA is downloading configlet in all recently synced forks for all our tracks.

44

FYI, the Julia run succeeded, the R run gave a 403. Do we need to randomize the times at which these run?

45

This PR aims to address that.

1 Like
46

I noticed that the following PRs, all of which target maintained tracks, were automatically closed by the GitHub Actions bot but haven’t been reopened:

I’m wondering if there’s a reason these PRs weren’t reopened. Have the tracks decided not to include them, or were they possibly missed after being closed by the bot?

Would appreciate any clarification on this.

47

I reopened kotlin just now.

The most likely reason is that all (most?) of these are maintained tracks so we (guardians / cross-track maintainers) could not reopen them as we don’t have rights.

You can ping the maintainers on the PR for example using @exercism/csharp (which is @ErikSchierboom).

1 Like
48

… and shouldn’t reopen them :) Maintained tracks should be left to their maintainers to manage however they prefer.

3 Likes
49

Also, it’s only been a couple of weeks since the PRs went out. Some maintainers may have missed the notification, not understood what the PR was about, or could be prioritizing something else at the moment.

Were all maintained tracks PRed? I noticed some maintained-solitary repos like Erlang and Red weren’t.

50

Yes, maintained-solitary tracks weren’t (for the most part)!

I had raised a PR on one of the maintained-solitary repos, and the github-actions bot responded saying the track didn’t have a specified maintainer, for example: powershell PR #415

So I refrained from raising PRs on these since we had decided not to add this for unmaintained tracks. I wasn’t sure whether we should include them or not, so I decided to skip them for now. Let me know if you think otherwise!

51

powershell is maintained by @glaxxie

Some of those track workflows need updating to reflect their current status :laughing:

52

maintained-solitary means that there is a single maintainer so they are in fact maintained. They can provide the obligatory review for others’ PRs, but they can’t provide that review for their own PRs. The cross-track-reviewer team can provide that review so that’s why the bot pings them. I’ve noted in the past that the message is a bit confusing in this kind of situation and perhaps a different message should be used for maintained-solitary tracks to clarify that the track IS maintained. The workflow should probably only trigger in a maintained-solitary repo when the PR author is also the maintainer, but that’s a separate discussion I think.

2 Likes
53

As a follow-up, maintained-autonomous tracks are a special case where all the track maintainers are also cross-track-reviewers so PR reviews are optional before they get merged. Since reviews aren’t required, that GHA won’t trigger on PRs to those repos.

1 Like
54

I wonder if the solidarity ping checks whether the PR author is the track maintainer or not. And, if it doesn’t, how hard would that be to change? If the author is not the maintainer, there’s no need to ping cross track maintainers.

55

I’m completely out of the loop for this topic, and hasn’t really check on exercism for like 2 weeks now.
If you don’t mind as of now I would like to opt-out of this for the PowerShell track until I can have a better grasp of what’s going on (unless this is mandatory).
Thank you for the tool though.

56

It checks if the PR author is a guardian or cross-track-reviewer using github.rest.teams.getMembershipForUserInOrg to check those specific teams. I suppose you could use the GH context to get the repo name and then retrieve the track slug. Then you can check if the PR author is a member of that team

57

Why is this bot impersonating me? I’m noted as the author of the commit on this PR:

This should not be happening. I already merged an earlier PR where I didn’t notice this…

58

Looks like the default behavior of the peter-evans/create-pull-request action. Please change it to the normal “github-actions[bot]” or whatever.

59

A PR has been raised!