so for instance, if you push code to another folder in that repo other than proxy, will the proxy service redeploy?

Yes, exactly

don't you want an inverted rule then?

Why? I want to only deploy proxy when code inside proxy is changed

not sure, try it?

I actually think the answer is that I need to do proxy/** vs /proxy/**

we should make that more explicit

So was I right? Is that why it isn't working?

oh, I haven't confirmed anything. I thought you had lol. sorry

but I can help try

I have not had a chance to open a test repo. I might be able to get to it tomorrow. If you are able to test before that, by all means

But I don't think think that is the issue. Or at least, it shouldn't be the issue. I wonder if the new build system is part of it? Idk. Becuase the site / docs shows using /path/**. And this isn't the first thing that the new builder messes up on when it comes to mono repos. So that is also worth looking at

I'll def make a ticket for that.

<#1250987443918995466> (it is what got me <@&875753109501141003>)

But idk since i have only ever used v2. I have never used anything else. So ,,, I it is just a speculation

but root directory weirdness has been observed. best case scenario is docs are unclear

root dir + monorepo

Yes. Either the issue is the docs do a bad job explaining where root is; or this is just a bug.

I will likely test it out tomorrow at some point. Just not going to bother making a new test repo right this second.

for sure. i'll see if I can test something too

I was able to get a push to the main project. Removing the leading /, didn't do anything. So ,,,, going to need to make a test repo if I want to actually find the cause.

Testing a few things at once. But yea. I found it out. It is the new builder. @matt 👍
Idk who to raise this to that can fix it.

The project id for the above : cd724b67-a692-4005-812c-617f8b9238bf
Lmk when I can delete it. Lol, I am still doing all of this on a trial plan account 😂

oh, extra info about the "few things" I was testing at the same time.
Service A has a watch path of /serviceA/** and service B has a watch path of serviceB/**
ServiceA is a nixpacks default deploy, and serviceB is a docker file.
https://github.com/CoderJoshDK/railway-mono-repo-test
I like keeping my repos "clean". So just lmk when I am free to delete everything

Hmmmm I guess this is also a different bug, but railway is claiming that one of the deploys failed. However, clicking on details, takes me to an older dummy build. bcddd97e-3c35-44a5-9221-3b7cb1b507c1. Not really sure what it is from
It is the removed one. But even if that one was a failed deploy, it shouldn't matter. There is a more recent successful build.
No idea what went on here. And I won't be exploring the cause of this bug. Just letting you know about it

thank you so much. can confirm the watchpattern bug. thank you!

I am going to delete all of the services and repo now. I can get it back up if need be

[BUG] Watchpath is ignored for v2 builder + mono repo

Any insight / update on this?

Coming back to this. This bug is still here 👀

Totally understand that it is a low priority bug. But it should help reduce the redundant builds. And if there are a bunch of build issues going on … 👀

yes it is, just had my fellow conductor bring it up to me in DMs

cc @christian - watch path bug

!t

Thank you for flagging. I've created a bug report for this issue.

I could be delusional … possible. But I think this bug is still live? Any update on its progress?

yep bug is still there, the v2 builder is currently in an unmaintained state and we do not recommend it's use right now, we are currently focusing on stateful workloads on metal and thus have put the v2 builder on the backburner

besides, the new legacy builder is faster, we now use buildkit and stream each layer compressed to the registry

Hmmm, so I should switch everything to the old builder. Just double checking

that's correct, the new old builder! it's faster, but it still doesn't support private networking though

👌 thank you