Any way to skip redeployment if github ci is skipped?

Here's what I see on dashboard, railway is granted all accesses in my org on github. On github I can skip actions on commit by using [no ci] as part of commit messages, I'd like railway to not redeploy app if I do that. Is that possible? Right now the redeployment triggers, as far as I udnerstand it.

5908e018-e6a0-42ee-b4f6-04dab8bbe6fb

wouldn't check suites be what you want?

Well, the 1st thing is - I don't see the flag for them anywhere 😅 I assume it should be on my screenshot but it isn't? If it's possible to just set up some env var - what is the exact name? 👀
Next thing - I'm not sure how check suites will behave woth skipped ci. Skipped ci means no workflows are running (since they are, well, skipped), so potentially railway would still redeploy. But to test this, I need to enable them first.

Do you have "Read and write access to actions" in your Railway installation at https://github.com/settings/installations, and do you have GHA workflows in your main/dev branch?

The way I have it setup:
There is github organization with two owners. One is my "personal" profile, the other is "service" github profile. That "service" profile created the team within railway, my "personal" profile is also set as the admin of team on railway.

The installations for organization on github looks like this:

And yes, I've set up a workflow on dev branch.

by default this is what happens when actions workflow fails :

And if it is skipped with [no ci] in commit message, then railway just deploys.
Anyway, the easy thing i'd like here is some simple way to trigger on specific tag in commit message, like [railoff] should tell railway to skip deployment, ideally

What you can do if you already want to give a manual label or tag,

Setup your '/health' endpoint in such a way that it'll fail (not return 200) if your specific label or tag is present
That way you can change a Bool in your config file or code or whatever and when the Bool is correct then it'll pass the health check and thus deploy and replace your old deployment
if the health endpoint fails
it will just retry for a bit until it times out and it will never be live deployed replacing the prior one
If you wanna follow the exact same format as your github [no ci]

you can make your healthcheck query the latest commit in your chosen branch and extract the commit message,

# healthcheck endpoint

commit_msg = # handle your api logic in fetching the latest message

if '[no ci]' in commit_msg:
return 500
return 200

with this type of solution the docker will rebuild (which i don't want) and service will try to redeploy (which i don't want).
If I ever go with workaround, I guess i'll just introduce a job in github actions that will do essentially what you describe.

Also, I already have /health chekpoint and it serves an original purpose, overburdening it with functionality it shouldn't really have doesn't feel good to me 😅
But I could see this working for some people, aye

wouldnt matter if it fails the original health endpoint if you're not deploying it anyways right?
so you want to stop it at docker and not railway really

it would eat more resources from railway

very true!

I mean, they don't bill for it I guess, but I still don't want to run stuff when I can, well, not run stuff

i do think building a deploy is billed right?

We're all friends here 🤗
Tbh, I'm not sure about billing 🤔 It would make sense, I guess?

you could technically
oh wait
yeah
you could make a different branch for railway isolated deploys
you can protect that branch and have an action automatically merge all main into that branch aslong as the commit msg is not [no ci]

I think you should probably do it the other way around, but ye, nice thinking.

What I'd do as a good hack : create a blueprint branch which is not connected to railway in any fashion, then when I'm ready to run my CI in dev branch and deploy to railway, I just add sth special to commit message and github workflow auto-merges my blueptint to dev, which is connected to both real CI and railway.

This will work, but well, I already have dev and main, creating a thrid branch is overkill imo, but ye - it's a good solution in terms of resource usage 🥳

thanks alot for your constructive critism
i would just be scared someone gets rid of the branch that also works on the repo with me