It looks like @Meatball is also a gdscript maintainer
1 Like
If you’re going to work on a WIP track for a while, it might be worthwhile to become a maintainer there. Until the track goes live, you can merge without reviews.
1 Like
I’m up for it — what do I need to do to become a maintainer?
And can one big sync be a single commit?
Generally speaking, I have nothing against you becoming a maintainer. I think longevity-speaking, there is a need for a new maintainer to make the track actually come to a finish line. I generally don’t have the motivation and the time at the moment, frankly speaking, to do a project like that. I also realize that there will be a difficult time to get things to track if none of the maintainers (including myself) is inactive. And with how the system works, if I am removed and you are added, you will still have the same problem. So my idea here is that you can be added as a maintainer and then you can ping me on discord or github (forum works, but I do not regularly check the forum). And I will review your prs and be able to help out with the exercism parts.
As for a single sync, I will discourage that since it is both hard to review and it can make changes hard to track.
1 Like
If you’re removed before launch, the track at launch would be maintained-solitary, and the cross-track reviewers can provide the necessary reviews since a maintainer can’t review their own PRs.
If you’re a maintainer and become inactive after launch , the track would be maintained, and cross-track reviewers can’t help. That becomes a problem with inactive maintainers because they can’t provide the reviews for the one that remains active (one of my tracks is going through that) so track development slows down a lot. Pinging Erik or Jeremy can help in an emergency, but it’s not a sustainable practice.
If everybody gets removed, the track is unmaintained at launch. and then cross-track reviewers can merge without reviews. That’s not great, but that means the track won’t be abandoned.
1 Like
It would be true if I were the sole maintainer at the moment, which I am not.
1 Like
That should only matter after launch. WIP tracks don’t require reviews. You should just need someone with write access. So codingthat as a maintainer would be fine up to launch. Then yeah we’d to take a look at the maintainer team going forward.
1 Like
Thanks for approving the latest ones @Meatball ! Three of them are ready to merge if @pfertyk or @BNAndras or someone wants to give me access.
The fourth, Sync and add `reverse-string` tests by codingthat · Pull Request #79 · exercism/gdscript · GitHub , says “2 workflows awaiting approval — This workflow requires approval from a maintainer” still…does that mean 2 maintainers need to sign off on it?
Meanwhile, added more PRs: Once these are all merged, we should be fully synced.
@IsaacG / @Meatball , I’ve created a PR to update to the latest Godot per @pfertyk 's comment on Update Godot to the latest stable version · Issue #38 · exercism/gdscript · GitHub .
OK, the CI was failing. I added some fixes for that and it this time they pass:
Update: Thanks for merging, @IsaacG and @Meatball ! So…would it be possible at this point to add me as a maintainer, so I can try it out on the site and help with the final launch pieces? (I believe it’s mainly filling in the top-level documentation.) Is that something you can do as maintainers or does it need to go through kytrinyx?
1 Like
I believe adding maintainers would have to go through @iHiD and may require approval of existing maintainers.
1 Like
Ah, OK. So I think it just remains for @pfertyk and maybe @ErikSchierboom to weigh in re: approval? (I’m not sure where one goes to view the current list of maintainers, actually…)
Awesome, thanks very much!
So, in going to write up the local test instructions (INSTALLATION.md), I found I needed a script tailored more for students than for testing the whole thing. Is it OK if this script lives in the gdscript repo (under bin/) rather than the gdscript-test-runner repo?
#!/usr/bin/env bash
set -e
slug=$(basename "$(pwd)")
if [ ! -f "${slug//-/_}_test.gd" ]; then
echo "Missing test file: ${slug//-/_}_test.gd"
exit 1
fi
if [ ! -f "${slug//-/_}.gd" ]; then
echo "Missing solution file: ${slug//-/_}.gd"
exit 1
fi
solution_dir="$(pwd)"
output_dir="${solution_dir}/.test-output"
results_file="${output_dir}/results.json"
mkdir -p "${output_dir}"
(cd /opt/test-runner && bin/run.sh "$slug" "$solution_dir" "$output_dir") || {
echo "Test runner script failed."
exit 1
}
test_status="$(jq -r '.status' "${results_file}")"
if [ "$test_status" != "pass" ]; then
echo "Tests for $slug have failed:"
cat "${results_file}"
exit 1
else
echo
echo "Tests for $slug passed!"
fi
That script looks more like it is designed to aid people adding new tests/exercises. Is this the best way for students to test their code? Does it work on all platforms?
That script looks more like it is designed to aid people adding new tests/exercises.
Do you mean because of the existence check messages? I can improve them so they’re more contextual.
Is this the best way for students to test their code?
I’m open to alternatives, but offline, I believe so. It’s based on the preexisting Exercism GDScript test runner, just tailored toward testing the student’s solution from the current directory’s exercise instead of all exercises.
Does it work on all platforms?
I’m not sure. My intention was to start with this with a “currently requires bash” and ask others to help fill in the gaps if that’s not specific enough. (I’ve tested it on Linux only, but I’m not sure where the original script has been tested.)
This wouldn’t work on most Windows platforms. This introduces dependencies like jq. This creates a JSON file. Most tracks just run test runners depend on the language and/test framework only. Most test runners don’t write files to disk. Is all that additional overhead actually needed to run the tests?
That script also depends on a /opt/test-runner/bin/run.sh which I assume isn’t a file most people would have on their computer.