Starting small, I did a configlet sync for docs and metadata: PR #344.
It didn’t auto-close, but will need cross track maintainer approval at some point. It passed most tests, i18n still needs sorting.
Starting small, I did a configlet sync for docs and metadata: PR #344.
It didn’t auto-close, but will need cross track maintainer approval at some point. It passed most tests, i18n still needs sorting.
Merged. i18n isn’t usually not a big deal. Someone with write access just needs to add the ready-to-translate label and let the CI do its thing. It should go green on itself in a couple of minutes.
And of course I didn’t wait to check if CI passes first. Typical me. I’ll take a look tomorrow.
In your own time. I’ll think about Jinja2 stuff.
On older tracks like this, that haven’t been maintained for a while, it’s almost guaranteed that there’ll be a couple of mismatches between some tests.toml files and their associated test suites. Configlet uses the toml files to judge if all tests are synced, but it can’t of course verify that the tests are actually in the test suite. Since these toml files were batch created years ago from the problem specifications repo, it’s certainly possible there are tests that were not present but are considered synced.
In this kind of case, you pretty much need to do a manual sweep through the test suites and compare them to the actual problem specs data. I’ve done that on CoffeeScript and Common Lisp before, and it’s a good bit of work. Having a generator though like I did on VB (thanks Erik!) makes a big difference though. You just make the exercise-specific template and regenerate the suite. You don’t need to cross-reference everything.
I’ve added a Jinja2-based test generator in PR 351, with a couple of exercises for basic validation. I’m sure we’ll want to refine it further as we template a wider range of exercises.