Timeout in CI/CD script #400
Comments
|
There are a few things that are not clear.
CS-Script should not restore the package twice while executing a single script. I think it is a race condition that we have here. Can you share the sanitised version of the cicd-increase-versionnumber.cs? |
|
And if .NET9 somehow kames the difference you can always rollback to v8.0 |
|
There is also an inefficiency (but not a problem) in the package restore operations. For the apps, you do it in the |
…T_PACKAGES` nvar. Previously only lookup did. Triggered by #400.
|
Here is the full code of the "cicd-increase-versionnumber.cs" file: //css_import ../_References/Submodules/zeta-shared-ci-assets/DevelopmentTools/CentralScripts/Afx.cs;
using System.Threading.Tasks;
using ZetaSoftware.CentralScripts;
public static class Processor
{
public static async Task<int> Main()
{
Afx.Init();
return await Afx.RunMain(async () => await processTasks());
}
private static async Task processTasks()
{
// Immer eines hochzählen.
BuildUtilities.IncreaseVersionNumber();
// NuGet-Pakete aktualisieren.
CompilationUtilities.HighLevelUpdateAndRestorePackages(@"${ScriptFolderPath}");
}
}It is rather short, because it includes the "Afx.cs" which in turn does include other files. The start of the "Afx.cs" looks like this: //css_nuget Newtonsoft.Json
//css_nuget morelinq
//css_nuget SharpZipLib
//css_nuget RestSharp
//css_nuget ZetaShortPaths
//css_nuget ZetaDeployer.RuntimeUploader
//css_nuget QuickUploader.WebApiAccessor
//css_nuget NuGet.Versioning
//css_import ./Logging.cs;
//css_import ./ProcessUtilities.cs;
//css_import ./SpecialFolders.cs;
//css_import ./StringUtilities.cs;
//css_import ./FileUtilities.cs;
//css_import ./FolderUtilities.cs;
//css_import ./FolderXCopy.cs;
//css_import ./FolderXCopyUtilities.cs;
//css_import ./FolderZip.cs;
//css_import ./AppOfflineUtilities.cs;
//css_import ./BuildUtilities.cs;
//css_import ./QuickUploaderUtilities.cs;
//css_import ./CompilationUtilities.cs;
//css_import ./FileSyncUtilities.cs;
using System;
using System.Diagnostics;
using System.Collections.Generic;
using System.Net;
using System.Text;
using System.Text.RegularExpressions;
using ZetaSoftware.CentralScripts;
using System.IO;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;
using System.Reflection;
namespace ZetaSoftware.CentralScripts;
// ... |
Probably this is not possible in my scenario as I have to use .NET SDK 9 since my applications have to be compiled to .NET 9. The start of my ".gitlab-ci.yml" starts like this: image: mcr.microsoft.com/dotnet/sdk:9.0
default:
tags:
- ubuntu
workflow:
rules:
- if: $CI_COMMIT_MESSAGE =~ /^(wip|skip)(\([\w\s-]*\))?:/
when: never
- when: always
stages:
- build
- test
- nuget
- github
variables:
#...I do not know whether you are aware of the CI-CD concept of GitLab. Basically the above defines the Docker image to use when running the CI-CD job and then it runs the whole script in a "GitLab Runner" on a separate Ubuntu server machine. |
|
That's a very challenging problem to solve.
|
|
Thank you, Oleg, The multiple restores happen since ever, in my opinion. I do think it happens when I have a script that includes another script wich in turn includes yet another script and/or includes NuGet packages. I get this on my Windows machine, too. |
|
OK, I will recheck this scenario. I hope this is the case because we can easily address the nesting if it cause the problem |
|
Attached is an example.zip that generates this output: c:\Ablage>run-a.cmd
PUSHD
CD /d c:\Ablage\
dotnet tool update --global cs-script.cli
Das Tool "cs-script.cli" ist bereits installiert.
css -config:set:LegacyNugetSupport=false
set: LegacyNugetSupport: False
css -nuget:restore "c:\Ablage\\a.cs"
Restoring packages...
morelinq
Mapping packages to assemblies...
Restoring packages...
morelinq
Newtonsoft.Json
Mapping packages to assemblies...
Compile: OK
css /dbg "c:\Ablage\\a.cs"
A
B
POPD
EXIT /B 0
c:\Ablage>It seems that it tries to restore "morelinq" twice, although it is only referenced in file "b.cs". |
|
Great, thank you. |
|
Since the "stalling" only occurs during CI-CD runs, and I did not yet integrate it into a CI-CD script yet, I cannot say whether it hangs or not. I can try to set up a test repository, if this helps. |
|
Leave it with me for now. I know in your case it's a container but I would prefer to cover all bases. I have already done some chanegs triggered by this very ticket. Let me add the restiore-optimization and then I will do the release and you can test it |
|
Awesome, Oleg. Thank you very much, again 😊 |
--- ## Changes ### CLI - #400: Timeout in CI/CD script - Assorted nuget support improvements triggered by #400 - removed doc zip files to not to upset WinDefender - removed unnecessary nuget restore step for adding package dll's location to the search dir. It was adding no value since search dirs play no role in nuget related scenarios. - Now nuget restore and asembly lookup are both respecting `CSSCRIPT_NUGET_PACKAGES` nvar. Previously only lookup did. Triggered by #400. ### CSScriptLib - no changes
|
Hey Uwe, I have just published v4.8.24 release. This release contains multiple NuGet-related changes. While none of them directly address the problem you are experiencing, altogether they may provide the improvement you are looking for. The changes:
This is what you can do now:
|
|
That's a wonderful Christmas present from you, @oleg-shilo 😊🎄 Thank you very much, I will start using it immediately and will report back after some time of using it. |
|
Merry Christmas to you and your family too Uwe. |
We talked about this in a previous issue; unfortunately I'm still getting constant timeouts in various of my CI/CD scripts. I do not find any pattern on why this happens in some scripts but not in others.
This is the full log output of one CI/CD build script on my GitLab:
My question:
Do you have any idea what might be the issue here?
It startet happening when .NET 9 came out and the Docker image uses the .NET 9 SDK.
The text was updated successfully, but these errors were encountered: