FYI <@U0152P3VB5J> <@UB9K6R4JH> after the recent i...

# github-workflows-kt

[Piotr Krzemiński]

FYI @Vampire @LeoColman after the recent incident, I'm experimenting with Allow fallback to local bindings server if remote is down

[Vampire]

I'm curious how that should work in the end. For CI you could maybe do something like detecting downtime in the YAML and then starting the server and manipulating the script, adjusting and adjusting the consistency detection to first revert the manipulation.

But that will not work for executing the script directly or via Gradle or from IDE. Or for synching the script context in IDE. Maybe it could somehow be done if compiler plugins are possible.

And of course a non-ci solution need to not use Docker. :-)

[Piotr Krzemiński]

For now I'm planning to focus just on the CI part, so that existing workflows work fine.

Local development is another story, and right now it's already possible to work around the server's downtime by starting the service locally (I'd recommend Docker, why not?) and changing the repository's URL to point to the local one,

[Piotr Krzemiński]

For CI, so far I've got sth like this: https://github.com/typesafegithub/github-workflows-kt/blob/99129679fef103290066080e8cac54196307dab0/.github/workflows/test-workflow.yaml#L22 - subject to tweaking in several places, like a better way to wait for the server (not "sleep") or configurable url to replace. The general concept is IMO fine. One remark: right now it will use the fallback path in case of any failure in the step where the script is run, even if a user has a bug in their script and it doesn't even compile. I'm thinking if we should somehow try to catch the specific server-related issues, but I doubt there's proper API for this, and parsing the logs for specific phrases doesn't sound robust and may simply stop working one day

[Vampire]

so that existing workflows work fine.

Well, wouldn't have worked in my case either way.
There is also a "verify consistency of all YAML" so that also workflows not run on every PR are checked.
And since the switch of Kotlin compiler on server-side broke the Scriptexecution, also the Gradle task is run on CI as this did not break at the time of the server change, but it worked locally for one person and broke for another and on CI.

I'd recommend Docker, why not?

I'm talking about an automatism.
Recommending for manual use is fine.
But an automatism should not require it as it might not be available.

I hoped you depict something that just works everywhere. 🙂

[Piotr Krzemiński]

I'm afraid there's no generic solution that will work on the library side in all these cases because scripting is lacking extensibility. However, if you have some concrete ideas, please share!
For starters, I'm planning to address solely the server's availability issues in CI, let's see how it goes

[Piotr Krzemiński]

You know, we can either do nothing and ignore the problem, or experiment and provide mitigation for at least some use cases

[Vampire]

if you have some concrete ideas, please share!

I do not, that's why I was curious. 😄