[BUG] Watchpath is ignored for v2 builder + mono repo
I have a mono repo project
project id: 1b326884-0c17-43ed-9b52-f443662e8f50
And I have multiple services with a root (like
/proxy) and then a watch path that is just /proxy/**. But all of the services are being re-deployed, when I push any change.
This should be valid. At least, if I am reading the docs right. For example:
Note, if a Root Directory is provided, patterns still operate from /. For a root directory of /app, /app/**.js would be used as a pattern to match files in the new root.
31 Replies
Project ID:
1b326884-0c17-43ed-9b52-f443662e8f50so 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 changednot 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 atI'll def make a ticket for that.
<#1250987443918995466> (it is what got me @Bug Basher)
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 everythingHmmmm 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
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
New reply sent from Help Station thread:
This thread has been escalated to the Railway team.You're seeing this because this thread has been automatically linked to the Help Station thread.
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