^ I believe I've found a bug with
^ I believe I've found a bug with Workers CI/CD, what's the best place to report that? (I was able to reproduce the issue, and it seems related to my setup and how Workers CI is triggered)
5 Replies
Hey @ac ! Could you send the build UUID that's stuck in a queued state? It'll be in your address bar like so
.../production/builds/<build-uuid>Sure, one of the builds was 54e379f7-ca8f-473c-985b-ed95785000f1 (I cancelled it). The issue I'm seeing is that if I make a change in the monorepo that is skipped by all the Pages apps in the monorepo (because the change was only in a worker's code), sometimes it makes all of the worker builds get stuck in queued state forever.
Ah ok I see you've got 5 workers connected to the same monorepo. When you push a change it'll cause all 5 workers to get a build queued and since we currently only allow 1 concurrent build at a time it'll take a while before the worker you actually want to get built, will get deployed
We are working on implementing build watch paths https://developers.cloudflare.com/pages/configuration/build-watch-paths/#:~:text=When%20you%20connect%20a%20git,build%20for%20a%20given%20path for Workers CI/CD
Cloudflare Docs
Build watch paths | Cloudflare Pages docs
When you connect a git repository to Pages, by default a change to any file in the repository will trigger a Pages build. You can configure Pages to include or exclude specific paths to specify if Pages should skip a build for a given path. This can be especially helpful if you are using a monorepo project structure and want to limit the amount ...
Which will let you filter for changes on certain paths, and should be out pretty soon! Will ping you here once it's out!