I’d prefer PRs for the docs, filepaths and metadata.
For those interested, the Github action is in PR#2950 in the Java track.
@jagdishdrp with raising the issues for tests, would it update or close the issue it previously raised (if it has not been closed by the next run)?
I’ve pushed a commit with the necessary changes, the workflow will now avoid creating duplicate issues. If an issue already exists, it will simply update the existing one instead of opening a new one.
Thanks for bringing it up!
I’d also like to have such an Exercism wide GHA, but would prefer having an allow- or deny-list of exercises to sync.
PHP track has it’s own script for sync’ing, reading the list of exercises to sync from a file. This allows us to have appr. 50% of the exercises to sync automatically while the rest is still outdated too much for configlet sync.
Nice work, @jagdishdrp!
I think it’s fine to have this Exercism-wide, but I’d like to have an opt-out (as in a do not install) for any tracks that don’t need/don’t want this.
Python is fine for now with a combination of our existing scripts and manually syncing. I do it often enough that I (usually) have very few issues.
The PR on the Java track has been successfully merged, and the testing has been completed by @kahgoh, and everything has been found to be working as expected.
This updated workflow is now fully standalone and functions independently without relying on additional directories, unlike the earlier version. It has also been refined to follow the Exercism GitHub Actions best practices, notably by pinning the runner OS and setting an appropriate timeout.
The workflow has been split into two distinct jobs:
docs, metadata, and filepaths, and raising a PR.This makes it modular, so maintainers like @IsaacG who are interested in only one part can remove the other, and tracks that already have existing systems (e.g., @BethanyG’s) can opt out entirely. As I understand, using all actions from the github-actions repo is not mandatory.
The workflow is scheduled to run monthly (currently on the 15th), but this frequency can be easily adjusted by modifying the cron field in the workflow file. It has built-in safeguards to avoid redundancy. It will only raise a PR if changes are detected and will not create duplicate issues for tests.
That’s the full proposal, happy to hear any feedback!
Finally, the workflow is designed to run monthly (on the 15th) without raising duplicate issues. It raises a PR only if syncing is needed.
I know we’re starting with running it on 15th of each month on the Java track, but wouldn’t each track decide when to run the action - similar to how the tracks schedule the configlet action in their github workflow (Java’s configlet action config for example)?
Yes, the frequency and timing of the workflow can easily be changed by updating the cron field in the workflow file!
I’ll update the proposal accordingly!
PR has been raised on the github-actions repo!
Reopened PR. 
Test are running. Not sure how many/which kind of approvals are needed.
Edit – and you have feedback!
And that too at so many instances 
Will have to look into it after a while
Would it make sense to add a runner for this workflow to unmaintained tracks?
So far, I’ve raised PRs for tracks that expressed interest in this forum thread. I also submitted PRs to a couple of unmaintained tracks, but then realized it might be better to check in here first.
Since those tracks don’t have active maintainers, adding PRs to set up the runner there could be useful. As for maintained tracks, I assume maintainers will come across the workflow in time and can opt in by adding the runner themselves (though please correct me if I’m off on that).
Open to any thoughts or suggestions!
Probably not. Maintaining a track takes time and work. If there is no maintainer, there is no one to put in the time managing the track. Without someone to manage the track, there is no one to handle PRs or issues.
Cross-track reviewers get pinged for unmaintained repo PRs so there is in fact someone to handle merging the PRs. We’re already merging dependabot PRs so this isn’t much of a lift. I would have the GHA only sync docs and metadata though. Updating tests definitely should be by a maintainer.
… so long as the exercises are initially in sync with the problem specs. If they are, syncing changes as they are made to the specs should be relatively simple. However, if they are not currently in sync, getting them in sync is a bigger lift.
We can update the workflow in the github-actions repo to accept two optional boolean inputs that control which jobs to run. This way, we can run only the job that raises PRs (which can be merged by cross-track maintainers) and skip the one that raises issues, since that usually requires someone active on the track to review and manage them.
It’s unclear to me what you mean here. The documents and metadata would come from problem-specifications so those would have been initially in sync unless the previous maintainers edited the instructions directly instead of using appends (which happened in Julia a while back).
If you mean the tests, I’d expect configlet to only tell half the story anyways. On multiple tracks I’ve maintained, I found test suites that predate the bulk metadata.toml creation. Configlet as a result thinks multiple canonical tests are present when in fact there might not be any. So an automated issue / PR is potentially continuing this issue, when really what we need (and don’t have currently) is a maintainer to do a deep dive and find out what actually needs to be synced.
Some of the unmaintained tracks are years old. They might be using a years-old version of the specs and/or instructions that were hand edited and/or were never aligned with the specs.
The tests may very well not be aligned with the current problem specs. For some of those, the docs and tests are currently aligned with each other. Updating the docs to match the problem specs would cause the docs and tests to disagree.
Getting unmaintained tracks synced once with a deep dive should help a fair bit with this.
Right, so we’re in agreement that those tracks need to have a deep-dive. I was just not seeing eye-to-eye with you on how much of a problem updating only the docs and metadata could become.
So yeah, let’s table adding this workflow to unmaintained repos for now. Later this year, I can start identifying candidates for a deep dive, and if anyone’s interested in helping, we’ll make our way through those.
Later this year, I can start identifying candidates for a deep dive, and if anyone’s interested in helping, we’ll make our way through those.
We should probably start a separate topic for this discussion. Once the deep-dive is complete, I’m happy to help with adding the workflows wherever needed!