Build/deploy information is not displayed after upgrading to 2023.05
Hello Team,
Any chance that someone can help here?
After upgrading TeamCity to the latest version (2023.05) I spotted an issue with displaying build\deploy information for some pipelines, not for all.
In the screenshot, you can see that 5 assemblies are found, but they are not displayed. Also in developer mode, you can see a 404 error in the console. What is interesting is that such a problem does not occur for all pipelines and occurs only when using the Sakura UI.
Please sign in to leave a comment.
I am having a similar issue. The home page shows "No builds" for all configurations in Sakura UI mode.
If I click into a configuration I do see the status of the last several builds. So there are builds.
I also get lots of failed requests in the browser log
Hello,
Could you please reproduce a problem and record the network requests resulting in the error, save them as a .har file, and share them with us via our secure upload service?
Thanks,
Guilherme
Upload id: 2023_06_01_27DQfSUSdSAu84wso1JRvf (file: teamcity.har)
Just to backup what Nate reported. we are seeing the same too since our upgrade. Our workaround has been to switch back to the legacy UI which works fine.
I am also experiencing the same issue after the upgrade to 2023.05 on some but not all of my build configurations.
If I switch to the branches filter the builds show and as per other comments the legacy UI displays the builds correctly.
Hello Team,
I found where issue is.
For my case, adding port 8080 to the link helped
I noticed that when the request fails with a 404 error, the request was sent to the server with port 80.
Changing the port to 8080 worked for me as well.
Unfortunately, none of the above-mentioned workarounds seem to work for me. The problem is a nuisance. Swift remedy would be very welcome!
It's Denis - TeamCity Frontend engineer.
We are looking into the issue but still need some additional information.
Can you please show the Server URL (you can find it in "Administration > Global Settings > Server URL")? Does it contain the :8080 port?
I can't find the attached HAR file - I see only the file name, not the file itself. Can you try re-send it again, please?
In our case, the Server URL does not contain any port. The HAR file was sent from someone else (Nate Barish, https://teamcity-support.jetbrains.com/hc/en-us/profiles/1087492924-Nate-Barish), and I do not know how to create one.
I know that we don't in our setup - we do use HTTPS but via an IIS based config setup as had to create it before TeamCity finally got around to implementing support for it.
Not sure... not an IT person, sorry. I see this in Administration->HTTPS Settings:
The screenshot says you do not use our Built-in HTTPS.
We will wait for another HAR file from Nate. Meanwhile, I try to look for other reasons behind the issue.
To fix this issue, we recommend changing the IIS by tuning the maxQueryString parameter in the server configuration. You can find more information on how to do this in the official [Microsoft Documentation](https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/requestlimits/).
Why would the update have changed things in that respect?
I tried to post my web.config contents but my response seems to have got discarded - needless to say this did fix things for us. Note for others I had to add maxQueryStringLength="4096" to the httpRuntime node in web.config as well as the maxQueryString="4096" to the requestLimits node within requestFiltering. Just doing the latter from the Microsoft Docs was not sufficient.
The TeamCity itself does not change anything in your infrastructure and configurations. Still, as the product evolves, we implement new features and apply optimizations.
In your case - we unified some requests to decrease their amount. Union meant increasing the length of some requests. Depending on the IIS version, there are different allowed lengths. In your case, it’s supposedly 2kb (the default value for the IIS 10). This is the heritage from the earlier Internet Explorer times when the IE allowed sending requests only of 2048 bytes in length at maximum. Since we do not support old IE - we do not consider these limits as show-stoppers anymore. However, we will add the recommendation regarding the IIS configuration in the documentation.
Although we are considering changing our request methods to POST, no decisions/ETAs exist.
UPD: until you confirm the fix helps, it's just a hypothesis regarding the query length.
Ok, thanks for the explanation. That way, the request length could indeed have grown above a standard threshold in place.
I will try to get hold of our IT people to change that setting in IIS and will let you know whether it helps. We will first try the change along the MS documentation, and in case of failure follow Kiwidude's recommendation to add maxQueryStringLength="4096" to the httpRuntime node in web.config as well as to the requestLimits node within requestFiltering.
Thank you both, Denis and Kiwidude!
Denis Lesnik Thanks for the information.
Increasing the maxQueryStringLength fixed our issues.
Problem resolved then. I confirm it works. Thanks Gregory, Denis, and Kiwidude!
The issue was resolved for me as well. Thanks a lot for your help.