Sure! :slightly_smiling_face:
Also, I need some opinions before working on this. GitHub input file does not expand yaml anchors for example. This is getting unworkable without them as we have lots of repetition all over the place.
Would it be ok to preprocess the CI files through a script to generate the final workflow?
For one, using the yaml racket package we could use anchors…
and if we are processing using racket I am sure there’ll be lots of simplifications we can work on down the line.
I don’t want to spend time on this if people are against it, so speak up. :slightly_smiling_face:
For now, the only thing I would do would be to recreate our ci files using anchors abstracting away repeated steps. Create a racket script to expand anchors and use it to generate the final ci files.
The script could for example generate the ci file and automatically lint it using the github yaml linter before writing the output so there are no syntax errors.
This would force anyone changing the ci workflows to regenerate the ci files but I don’t see that as a big deal.
Comments/suggestions/vetos?
This sounds fine to me. #lang scribble/text might be the right language choice.
@pocmatos I agree that this is a good idea. A few more thoughts: 1. We should make sure that CI breaks if they don’t get re-generated. 2. We should definitely do the generation in Racket code. 3. If you think GHA will add YAML anchors support in the future, we should just make that happen now. If we don’t, then I agree with @mflatt that scribble/text may be better.
I am not sure I understood your 3rd point. How does the fact that GHA may add or not support for anchors affect the use of scribble/text ?
If we could eventually stop having to pre-process the files, that would be great. Therefore, if GHA is going to add support for anchors in the future, if we use anchors now, we could just stop doing the preprocessing ourselves when that happens, and not change our files much at all. So that would be an argument for using YAML syntax and anchors as our abstraction mechanism. But if we’re going to be pre-processing forever, then choosing the best Racket preprocessing solution now is the right choice, and thus maybe that’s scribble/text.
Ah - understood. Let me take a look at the docs for scribble/text so I try to understand what a CI file in this lang would look like before commenting further.
Also, I will finish off current pending PRs (CI with docker and CI of i386) and will look at this afterwards
Some of these might be worth fixing (particularly the non-thread-safe time functions) https://lgtm.com/projects/g/racket/racket/alerts/?mode=list&severity=warning