To add a new language,
- Add a directory under
tests/day_99 called langname_personname (e.g. fortran_fred) with the simplest project you can think of in your language of choice (e.g. a solution.py file for Python or a Cargo.toml for Rust).
You can hard-code your solution to return "answer" no matter how it is called.
- Add a runner Command (see runners.py). This should include at least a run step, though potentially also setup and teardown steps.
- Add a setup step to the composite job (see action.yaml). There is usually already a
setup-langname action available but, if there isn't (e.g. with Guile) then it will probably require an apt-get install step or something.
- Add a new action input to allow users to specify the version/flavour/distribution of the language if this is configurable.
- Amend any of the markdown files in
tests/ to make sure that the functional and unit tests pass (functional tests are triggered by a GitHub PR).
- Update the README to say that we support the new language and describe the new action input in the README YAML block.
We could support more generic options such as binaries, Bash scripts and Makefiles but this will need some thought and might not be in the spirit of keeping things simple and fair.
To add a new language,
tests/day_99calledlangname_personname(e.g. fortran_fred) with the simplest project you can think of in your language of choice (e.g. a solution.py file for Python or a Cargo.toml for Rust).You can hard-code your solution to return "answer" no matter how it is called.
setup-langnameaction available but, if there isn't (e.g. with Guile) then it will probably require anapt-get installstep or something.tests/to make sure that the functional and unit tests pass (functional tests are triggered by a GitHub PR).We could support more generic options such as binaries, Bash scripts and Makefiles but this will need some thought and might not be in the spirit of keeping things simple and fair.