I finally bypass this limitation by using adding an argument to the module

This problem was linked to https://inedo.com/support/questions/9521

I ended up using powershell to add variables to a properties file of env.properties. Then used the "inject environment variables" post build step to add the file with those variables to by environment. #Powershell "APP_VERSION=$appVersion RELEASE_NUMBER_VAR=$releaseNumber IIS_APP_ROOT_NAME=$iisAppRootName APP_EMAIL=$appEmail" | Out-File env.properties -Encoding ASCII Then then used the Get-Release API to check and see if my selected release was a valid release. If not I created it with the Create-Release API. Then used the Inedo_BuildMaster Plugin for jenkins. Create BuildMaster Package - Post Build Step Variables: appEmail = ${APP_EMAIL} appVersion = ${APP_VERSION} buildNumber = ${BUILD_NUMBER} buildType = ${BuildTypeParam} iisAppRootName = ${IIS_APP_ROOT_NAME} iisHostNamePrefix = ${BuildTypeParam} After I figured out myself how to inject the Variables and use them properly this rout was much better because it let me know when the package was done deploying, if it failed, showed me the deployment log on failure and failed my Jenkins Job on Failure. Thank you for your answer though Josh!

I'm sorry but I'm not understanding what you mean by "queues" or "hangfire"...

There was a UI change; these are listed under "Containers" in the top UI.

Please note that retention policies are a paid feature. Although rules can still be configured in the free edition, they are always executed in dry run mode in ProGet Free. In addition, when multiple options are specified, then only packages that meet all of the selected criteria are considered. Please review the retention rules for more information Otherwise, the best place to look would be the retention logs, to show you what packages were considered.

My workaround for supporting scripts and modules is to essentially trick it. either specify the source and script source with the fqdn version of the url and then a shortversion of the url or, what I do, set up a iis front end for redirect urls. i.e. if your server name was repos and your domain was mycompany.com then you might set source to repos.mycompany.com:8624/nuget/myrepo and set script source to repos:8624/nuget/myrepo You can list and publish scripts or modules to the same repo and find-script will differentiate from within the repo. The more elegant solution, but more difficult, is to create a dummy website with real or virtual paths that use http redirects to the right sight. So you could set your source to something like repos.mycompany.com/source and that folder would redirect to the path on the different port. That's just a quick summary of the workaround, I realize that, I can provide more thorough examples if you would like.

There have been no changes to the way our products connect to databases in many years, so this is unrelated to an upgrade. However, it seems to be some sort of indication that SQL Server must be overloaded, or a network problem. This can typically be diagnosed / reviewed by the SQL Server DBA, who can see incoming connections, and which queries are taking too long, etc. But in my experience, just restarting the server you have SQL Server installed on fixes it like 80% of the time.

You can use an API key: https://github.com/inedo/upack#push Basically just use "api" as username, and the key as the password.

In this case, you can use the execute command line operation; please see Executing a Command Line Utility During Deployment in BuildMaster

When iam using USB to unlock build master showing error server is not started How can I solve this problem

Maven indexes are for search only, and don't have any sort of sensible ordering, so you won't see packages like you would on npm feeds.

Please refer to KB#1161 for how to update to TLS 1.2

I don't know if there's a better endpoint for this, but I have NuGet feeds and I use a PowerShell script like this: $response = Invoke-WebRequest -Method GET -Uri https://{proget-host}/nuget/Default -UseDefaultCredentials $response.Headers["X-ProGet-Version"]

I have emailed you the white paper that has a hands-on example for this.

Jonathan's correct, there won't be an issue; you can just replace the license key as needed. Of course if you're using paid features like LDAP or retention policy, those will no longer function.

ProGet is primarily developed in .NET (C#) and SQL Server. The front end, of course, uses JavaScript (TypeScript). Our other products use the same technologies

Hi Upgrade Path : Serveur Run the Hub installer on your Otter server -> https://s3.amazonaws.com/cdn.inedo.com/downloads/desktophub/OtterInstaller.exe Extensions (In Admin Menu) /!\ Git Extension shows 1.0.3 after its upgrade while it is expected 1.0.4. but it is working fine Agents. Do not update agent using Otter (Upgrade Agent). I had some trouble with this option. I'd rather upgrade using my software deploiement tools - (Remove old agent, cleanup folder, install new agent) Best Regards Philippe

Apparently this was updated in BuildMaster but not Otter, here is the documentation for the updated version that also applies to yours, substituting $CredentialProperty for $GetCredentialProperty: # ProGetCreds is an instance of Inedo Product Credentials (i.e. InedoProduct::ProGetCreds) with 'Allow encrypted properties...' checked set $key = $CredentialProperty(ProGetCreds, ApiKey); set $host = $CredentialProperty(ProGetCreds, Host); Log-Debug Getting ProGet package from $host with API key: $key; ProGet::Get-Package( Credentials: ProGetCreds, Feed: hdars-1k, Name: hdars, Directory: $WorkingDirectory ); Additionally, I will notify our product director to add an issue to fix this in Otter (it would still be backwards compatible, but the canonical name would become $CredentialProperty)