Sounds like the service is crashing because of connectivity problems with SQL Server; this is expected behavior, as the service cannot operate without a database and will crash if it can't be reestablished after a few tries. This is why it's not logged in BuildMaster's error logs (as those are stored in the database). You could see it in the Windows Event Log however. Short of fixing connectivity problems, you can just set service to auto-recover.

Pipeline variables are considered Configuration Variables, not Runtime Variables. When you use the Set Variable Value statement, you are creating a runtime variable in the current scope, or updating a runtime variable in the current or parent scope. If you want your scenario to work, you would need to do this... #create a runtime variable from $pipelinevar1, which will resolve to configuration variable set $pipelinevar1 = $pipelinevar1; # update runtime variable created in above scope { set $pipelinevar1 = somevalue; Log-Information value is as set here: $pipelinevar1; } #general { Log-Information value is as set in pipeline here: $pipelinevar1; }

If you want to quickly add something like this are familiar with C#/.NET you can already create a custom package store to do this, see: Extending ProGet Beyond that, we will consider this as a first-class feature as you suggested. If you have any specific thoughts as to what would need to be configured for the hooks please add them to this thread.

These days, the general workflow has really evolved to assembling artifacts into "packages" and then pushing to a package manager; basically Build > Package > Deploy I think the reason is that it's much easier to deploy known packages (then assemble them from artifacts). In this case, ProGet serves as the Package manager step.

Hi Alana This page (https://inedo.com/support/documentation/proget/core-concepts/connectors) has no info that I have to link the connector to my feed. Just add a little section at the end with a screenshot so the users sees what he has to do after creating the connector.

Thanks for the quick reply! Ok, that's a shame but understood.

Unfortunately it's a bug in IIS/COM API Library. There is no resolution, it "just happens" sometimes. On some servers, especially older ones, it seems to happen more frequently. Rebooting tends to fix more persistent ones. if it's an issue, then just put in a retry loop with a timeout.

Hello Charles, upack pack expects a directory, not an individual file, so the command should be: upack pack C:\location_of_upack_json_file C:\directory_containing_my_setup_exe --targetDirectory=C:\mytargetDir\build_artifacts

Hello Robert, Thanks for the bug report! I've filed this as PG-1047. NPM feeds were showing the download count as the total for all NPM packages, not just the ones associated with that feed.

Yes. Of course you will not be able to connect to NuGet.org as connector, or inedo.com for automatic updates and license activation. You can request a key from my.inedo and enter it in the installer.

Same issue here, tried with Local Users, LDAP and Windows AD, with and without API. Did anyone managed to solve this? Thanks!

At this time we do not have a Go repository planned. This is the first request for a private Go package manager, and we have other ones ahead in terms of priority (PyThon, etc). But we will consider it for the future.

Follow up question, would the file that is in the artifact already have had the key pairs replaced when the artifact was made? And do I need to deploy the config file first and then make the artifact or will it just automatically be part of it? What I'm needing to accomplish is deploy it using the same way if possible without having to replicate storage of the config in different apps. So replacing the key pairs under the new app if possible. I know it would make more sense to make it part of the original apps but I cannot here because this is strictly on-demand deployments and we want to keep the restrictions on the pipelines requiring deployment to stages in order for the real apps.

It's certainly possible in BuildMaster, but it's not a common workflow anymore. We have considered extending support, but the market generally is moving towards "many single-purpose tools" than "multi-function tools". The general flow these days looks like this: Source >> CI >> Package >> Deploy In this case, ProGet is the Package repository and BuildMaster is the deploy tool. The advantage to this workflow is that, the CI tool need only "create a validated package", instead of trying to deploy. By the way, I also recommend you to look at GitLab; we switched to it after extensive evaluations of similar "simple" tools (GitHub, BitBucket), as well as the enteprrise tools (Perforce, etc).

I tried on a different machine which runs Ubuntu 16.04.2 LTS and for some reason I no longer see the problem. Even more surprising is that both machines are virtual machines built from the same VirtualBox image. The 16.04 one was recently upgraded from 14.04. I guess 14.04 image is somehow broken and was fixed during the upgrade. I guess that's answers my question.