Using Ren-C As The Shell In GitHub CI

(Check this out, @giuliolunati ...!)

There's a feature in GitHub CI which lets you override the shell used in a workflow. You can do it for the whole workflow, or even on a step-by-step basis.

This got me to wondering what it would be like to use Ren-C as the shell for a step. It took a little tinkering, but I got it to work!

Here it is using an executable for Windows (that it just built) to test HTTPS reads:

- name: HTTPS Read Test
  shell: r3 --fragment {0}
  run: |
    print {== Hello From R3 HTTPS Read Test! ==}
    parse as text! read https://example.com [
        thru <h1> copy header: to </h1> to end
    ] else [
        fail "Couldn't Capture Page Title"
    ]
    assert [header = "Example Domain"]
    print ["Succeeded:" header]

And it works!!

What GitHub is doing is it's taking the body of what's in the run section and writing it to a temporary file with a random name off in some weird directory. Then it substitutes that weird name in for the {0} in the shell expression.

The New --fragment Option

There were a lot of details on the path to getting that working. But I'll just focus here on the new feature of saying that a script is a "fragment".

  • We Don't Want To Change Into the Temporary Directory The Fragment Lives In. Rebol has historically switched to the directory a script lives in, and on balance I think that's the right default. It helps the script find its own resources, where it has the most likely ability to neatly refer to files by short paths. But this is a lone file...there's nothing to gain by doing that, and it's a disruption.

  • I Don't Think It Should Need A Header, Either. It would be a competitive disadvantage in this scenario--compared to other shells--if you had to put a dummy header in there. By using a special name and a setting for "fragment" we have a way on the command line of saying "hey, this has no header, and I meant that".

  • GitHub CI Threw In CR LF, we need an excuse to tolerate it. Even though the YAML for the original code had just LF, the temp file for the run lines got CRs added. I'm still pretty bullish on saying we need to consider this just like a syntax error or any other illegal sequence of characters. If a strong stance isn't taken, then it screws everyone forever. But here the compromise is that you have declared this isn't the kind of file you'd be sharing...not a "full script"...so it makes it a bit more okay to strip the CR LF silently (On Windows only, though!)

:bulb: GitHub Action Dialects Might Have A Lot Of Potential :bulb:

Not everyone has figured out that this is possible, yet. But I found a post on the Julia forum while I was doing it, showing that a few people are catching on to the idea.

But what we can do in customization could potentially go quite a lot farther than "Bash control structures but in a language you are more familiar with". What the code does can be creatively tailored to the domain being solved.

A GitHub Action can make including the feature as easy as one line for users. And we have the advantage of being able to make single-exe tools that could install on all the container types. (All of them are 64-bit. Sorry, Red...)

Could be interesting. We'll see!

2 Likes

Agree :100: This area is interesting/exciting for a language like Ren-C, where the language flexibility ought to open up creative ways of semantically "wrapping" other tools with dialects.

2 Likes

A post was split to a new topic: The New Ren-C GitHub Action: Run Natively, Run on Web!