Posts made by ben

Looking deeper, I see that the raft repositories are supposed to automatically download changes, but that functionality is broken. I've filed this as OT-183 and also fixed the related bugs OT-184 and OT-185.

Hello Giri,

This command should work:

InedoAgentSetup5.8.1.exe /S /TargetPath="D:\program files\inedoagent" /port=46336 /UserAccount=LocalSystem

I changed TargetDirectory to TargetPath, captialized /S, removed the install argument, and added quotes around the file path with spaces in it.

Hello Stijn,

This issue is caused by a hidden version of the package: https://www.nuget.org/packages/Swashbuckle.AspNetCore/1.0.0--rc1.

I've filed this as PG-1146 and will submit a fix for my co-workers to review.

Copying John's answer from StackOverflow:

Maps are specified as %(key: value), here is an example plan that should help:

set %map = %(Web.config: @("Web.Beta.config", "Web.Release.config"));

foreach $key in @MapKeys(%map)
{
    set @values = %map[$key];
    Log-Information `$key = $key;
    Log-Information `@values = $Join(", ", @values);
}

Sleep 3;

Hello Chris,

By default, Git rafts are stored in C:\ProgramData\Otter\Executions\GitRafts[raftname] as bare repositories.

I don't think Otter git raft repositories will automatically download changes made outside of Otter - to pull the remote changes in this case, you could use the command git fetch origin master:master while inside the bare repository.

Could you capture a Fiddler or WireShark trace of the ProGet response? There should be an error message associated with the 400 (either There must be exactly one package., which would indicate a proxy issue or Package validation failed: followed by an error message, although from a quick glance over the source code, I don't see how that could happen for a NuGet package.)

Another possible cause is an IIS module, like WebDav, intercepting the request before it gets to ProGet.

Hello Tore,

I've fixed the 'syntax error at or near "IF"' error for future versions of ProGet on Linux, but that specific change script failing should not cause any problems. If you want to use the new AD user directory, you can add it on /administration/security/manage-directories.

I've filed the missing ChunkedUploads_* functions as PG-1142. They are missing from the Linux version of ProGet. I'll check to see if any other functions are missing.

Hello Bob,

You seem to have a typo in the feed URL. http://servername/nugget/feedname should be http://servername/nuget/feedname (with one g).

Hello Stefan,

Thanks for the bug report!

I've filed this as Windows#29 and submitted a pull request with a fix.

Hello Dmitry,

1. I don't think there's currently a way to delete Docker images through the API.
2. The blobs are deleted by the FeedCleanup scheduled task. You can run the task manually from /administration/scheduled-tasks, and it will run automatically once per day by default.

Hello beda,

It appears that npm 5.5.1 (the node:6.11.4 Docker image has npm 3.10.10 by default) strips anything after the last slash in the registry URL. To work around this, add a slash at the end, so --registry=https://proget/npm/my-feed-name becomes --registry=https://proget/npm/my-feed-name/

Hello Bruce,

I believe the Jenkins plugin does not want the leading slash on the path, so this should work: parent-folder,myFolder/**/*

Let me know if I misunderstood your question - I don't usually work with Jenkins.

My initial guess was wrong. The problem was that Ensure-Package assumed all directories would be explicitly listed in the archive. I've filed the issue as https://github.com/Inedo/inedox-inedocore/issues/45 and submitted a fix for my co-workers to review.

As a workaround until this fix is released, the upack command can create a upack archive in the format that it expects.

Hello Andrew,

I can't reproduce this locally. How are you creating the upack archive? Could you send me an example of a upack file that exhibits this behavior?

My guess is that the upack file has backslash path separators and that is confusing the InedoCore extension somehow.

Hello Kirill,

It appears that projects supporting .NET Standard create Portable PDB files instead of Microsoft PDB files. The current version of ProGet does not know how to read Portable PDB files, so it assumes they must not contain any symbols.

I've created a tracking issue for this: PG-1054

Hello Hugo,

That error message looks like SQL Server is not responding to connections. A StackOverflow user posted four possible solutions to this problem. Do any of the solutions on that page work for you?

Hello Curdin,

Is the connector associated with the feed (on the Manage Feed page)? Creating the connector makes it appear on the list of connectors that can be added to that type of feed, but it doesn't automatically add it as a feed connector.

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.

Hello Jon,

Config files are not accessible via imported deployables, but artifacts are, so you can create an artifact in the source application and then do something like this:

Deploy-Artifact ArtifactName
(
    To: $WorkingDirectory,
    Application: $ReferencedApplicationName(DeployableName),
    Release: $ReferencedReleaseNumber(DeployableName),
    Package: $ReferencedPackageNumber(DeployableName),
    Deployable: DeployableName
);

Hello Srinivas,

The port number is required in the binding, so it should be 127.0.0.1:80, or *:80 if you want it to be accessible externally.

From the documentation:

The value of this property is a colon-delimited string of the format: «IPAddress»:«Port»:«HostName» - You may leave the host name blank. You can set the IP address to "*" to indicate that the site is bound to all IP addresses. A port number is required.

Hello Etienne,

Unfortunately, the Docker client does not support windows integrated authentication. http://inedo.com/support/kb/1131/docker-feed-limitations

Hello Travis,

I was able to reproduce the bug. Otter sees the scheduled job with no "last run" date assigned to it and assumes that it's past the time the job is supposed to run. I'm discussing how to fix this with the team.

I think the fix in the past was for non-recurring scheduled jobs.

As a workaround, creating a recurring job with a plan that doesn't do anything, letting it run, and then editing the job to use the correct plan should work.

Hello Jon,

I would suggest using the variables management API. In this case, the endpoint would be GET /api/variables/packages/«application-name»/«release-number»/«package-number»?key=«api-key» to get all the variables associated with a package.

The legacy source provider is available in the same Mercurial extension. As long as the provider has Log command line arguments disabled, the Admin_ConfigureBuildMaster permission is required to see the URL with the password in it.

If the username or password has special characters that don't work in URLs, they can be encoded. Common characters that cannot be used in the username/password section of a URL without encoding include:

• \ (use %5C)
• / (use %2F)
• @ (use %40)
• : (use %3A, but don't encode the colon between the username and the password)
• % (use %25, but only if the percent sign is part of the username/password and not one of the above replacements)

Hello Graham,

Filters are what you should use in this case. You can add a package ID like MyCompany.SomeProduct or a wildcard like MyCompany.*. A long list might be hard to work with, since it's just a text box, but if you're only adding new things to the list every so often and not modifying the list all the time, it should be fine.

That is strange. If I go to [proget URL]/nuget on my installation, I get this:

Nothing to See Here

This URL is just the root for all of your NuGet feeds, and is not meant to be used or browsed to directly.

To access one of your NuGet feeds, use a URL like this:

http://proget/nuget/FeedName

Do you have some URL rewriting set up in IIS?

Hello bonju,

Running this on the database should give you enough permissions to manage permissions:

IF NOT EXISTS(SELECT 1 FROM [Groups] WHERE [Group_Name] = 'Administrators')
    INSERT INTO [Groups] ([Group_Name]) VALUES ('Administrators')

IF NOT EXISTS(SELECT 1 FROM [UserGroups] WHERE [User_Name] = 'Admin' AND [Group_Name] = 'Administrators')
    INSERT INTO [UserGroups] ([User_Name], [Group_Name]) VALUES ('Admin', 'Administrators')

DECLARE @AdministerRole INT
SET @AdministerRole = (SELECT [Role_Id] FROM [Roles] WHERE [Role_Name] = 'Administer')

IF @AdministerRole IS NULL
BEGIN
    INSERT INTO [Roles] ([Role_Name], [Role_Description], [FeedScopable_Indicator]) VALUES ('Administer', 'Allows unrestricted access to all functionality within ProGet.', 'N')
    SET @AdministerRole = SCOPE_IDENTITY();
END

IF NOT EXISTS(SELECT 1 FROM [RoleTasks] RT INNER JOIN [Tasks] T ON RT.[Task_Id] = T.[Task_Id] WHERE RT.[Role_Id] = @AdministerRole AND T.[Task_Name] = 'Admin_ConfigureProGet')
    INSERT INTO [RoleTasks] ([Role_Id], [Task_Id]) VALUES (@AdministerRole, (SELECT [Task_Id] FROM [Tasks] WHERE [Task_Name] = 'Admin_ConfigureProGet'))

IF NOT EXISTS (SELECT 1 FROM [Privileges] WHERE [Principal_Name] = 'Administrators' AND [PrincipalType_Code] = 'G' AND [Role_Id] = @AdministerRole AND [Feed_Id] IS NULL AND [PrivilegeType_Code] = 'G' AND [UserDirectory_Id] = 1)
    INSERT INTO [Privileges] ([Principal_name], [PrincipalType_Code], [Role_Id], [Feed_Id], [PrivilegeType_Code], [UserDirectory_Id]) VALUES ('Administrators', 'G', @AdministerRole, NULL, 'G', 1)

If it gives back an error about Cannot insert the value NULL into column 'Task_Id', that means the Tasks table is probably missing some values, and I can help with that if that's the case.

Hello Jamie,

There's not a way to do this through the BuildMaster interface, but if you have access to the SQL database, you can run this:

SELECT P.[Plan_Name], A.[Application_Name]
  FROM [Plans] P
  LEFT JOIN [Applications] A ON P.[Application_Id] = A.[Application_Id]
 WHERE CONVERT(VARCHAR(MAX), P.[Plan_Bytes]) LIKE '%call MyPlanTemplateName%'

There's a possibility of false positives because the SQL query doesn't actually parse the plans, but it should be able to give you a rough idea of where a template has been used.

Hello Jim,

You can run the ProGet service in interactive mode to see its logs:

• Stop the ProGet service.
• In Command Prompt or PowerShell, run .\ProGet.Service.exe run from C:\Program Files\ProGet\Service (or wherever you installed ProGet if you didn't use the default location).

It will run the drop path monitor every 60 seconds by default. The message for the drop path monitor starting is Executing DropPathMonitorExecuter....

You can edit Service.DropPathMonitorExecuterThrottle in /administration/advanced-settings to less than 60 seconds if waiting gets too annoying.

Immediately after the drop path monitor runs, there should be a message that says Scanning for packages in f:\dsc\droppath. This will be followed by Found f:\dsc\droppath\file.ext any packages it finds.

In order to be found, the package files must end in the expected extension:

• .tgz for npm feeds
• .nupkg for NuGet feeds
• .gem for Ruby Gems feeds
• .upack for Universal feeds
• .vsix for VSIX feeds

If an error occurs while trying to add a package from the drop path, it will appear on a line shortly after the Found f:\dsc\droppath\file.ext line, starting with Error installing package:.

Assuming ProGet.Service.exe is in C:\Program Files\ProGet\Service, there should be a folder named C:\Program Files\ProGet\WebApp. Does the WebApp folder exist?

Hello Timo,

The symbol server endpoint is located at http://hostname/symbols/FeedName. It looks like you're using the NuGet endpoint.

Each rule separately checks that all of its conditions are met before deleting a package. If any of the rules decide to delete a package, the package is deleted.

Hello Erick,

All of the conditions set in the retention rule must be met for the package to be deleted, so setting "delete old versions except the last n versions" and "delete unused versions not requested in the last X days" on the same rule will do what you want.

Hello Glenn,

The payload will contain:

• Event_Code (BLDCPP)
• Event_Description (Build Promotion Completed)
• Release_Number
• Build_Number
• PipelineStage_Name

For other types of event listeners, Event_Code and Event_Description are always included and the rest of the fields are from Event Details in the event log for that event type.

Hello Glenn,

The next version of the YouTrack extension will include a Find-Issues operation, so you'll be able to do:

YouTrack::Find-Issues
(
    Credentials: MyYouTrackCredentials,
    Project: IT,
    Filter: "version: $ReleaseNumber -resolved",
    Output => @IssueIDs
);

foreach $id in @IssueIDs
{
    YouTrack::Add-Comment
    (
        Credentials: MyYouTrackCredentials,
        IssueId: $id,
        Comment: Testing BuildMaster/YouTrack integration. $ApplicationName $ReleaseNumber.$PackageNumber -> $EnvironmentName
    );
}

Ah, I think the confusion here is because of the different meanings of the word "set".

If you don't select the deployables in the release template, it will have the default deployables available in executions. That is, if you do for deployable Foo and Foo is a deployable in the application, it will execute the code inside the block.

However, you can select specific deployables for a release and the for deployable Foo block will only be run if Foo is selected.

Hello Jon,

There is no deployable set in OtterScript deployment plans unless the execution is inside a for deployable DeployableName block. (for deployable blocks are displayed as General blocks in the visual editor.) Deployables use a separate working directory from the rest of the execution by default.

The person who told you you don't need to set the deployable may have meant that your plan doesn't need deployables. Deployables are just for organization, so you can think of deployables as folders. Everything that isn't in a deployable goes into one folder, and each deployable is a separate folder next to the default one.

Hello José,

That doesn't look like a ProGet error. Can you make sure the upack feed URL is correct? If you visit the upack feed URL in your browser, it should have something like this:

This is the API endpoint for the Universal universal feed. It is not intended to be browsed directly. To view the contents of this feed in your browser, visit the browse feed page.

If the upack URL displays that text, the error message is probably coming from IIS.

A ProGet error looks like this:

Hello Jeff,

I've fixed PG-1034 and PG-1035 in the next version of ProGet.

There is no configuration problem on your server.

Hello,

You can use Environments_ResequenceEnvironment in the native API to reposition your Build environment in the list.

Assuming the ID displayed when you hover over the Build environment is 4 and you have an API key abc123 with the native API enabled, accessing this page in your browser will move the Build environment to the first position:

/api/json/Environments_ResequenceEnvironment?Environment_Id=4&New_Environment_Sequence=1&API_Key=abc123

Hello Jeff,

There is currently a bug in the FeedCleanup task for Docker feeds. PG-1030 has been fixed for the next version of ProGet, but until then, disable the FeedCleanup task for any Docker feeds in /administration/scheduled-tasks.

Hello Peter,

Thanks for the bug report! I was able to reproduce the problem, and it will be fixed in the next minor version of ProGet (4.7.12).

PG-1029

Hello Jason,

It looks like the npm registry started returning empty responses about a week ago. It looks like they're having caching problems.

ProGet 4.7.8 and newer support the npm search API, so indexing isn't needed to search the npm registry, or you can wait for npm to fix the problem on their end.

UPDATE: this has been updated in PG-1632

__

Hello Jonas,

Deleting images isn't in the native API because the stored procedures only delete metadata, but if your CI server has access to the database ProGet is using, you can run the stored procedure to delete the metadata for the image and ProGet will automatically delete the files whenever the FeedCleanup scheduled task next runs.

Assuming your docker image is named proget:443/foo/bar/baz, the foo feed has ID 42, and the digest for the version of the image you want to delete is f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7, this SQL statement will work:

EXEC [DockerImages_DeleteImage]
    /* Feed_Id */ 42,
    /* Repository_Name*/ 'bar/baz',
    /* Image_Digest */ 'f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7'
GO

If you don't know the digest, https://proget/api/json/DockerImages_GetImages?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Published_Date, and https://proget/api/json/DockerImages_GetTags?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Tag_Name.

According to the mvn deploy documentation, you'd need this in the POM file for the project:

  <distributionManagement>
    <repository>
      <id>myproget</id>
      <name>My ProGet Feed</name>
      <url>http://progethostname/maven2/feedname</url>
    </repository>
  </distributionManagement>

If the feed requires authentication, you also need this in settings.xml (the <id> values have to match):

    <server>
      <id>myproget</id>
      <username>username</username>
      <password>password</password>
    </server>

If you want your snapshot versions deployed to a separate feed, you can add a <snapshotRepository> to <distributionManagement> in the same format as <repository> above.

After that, the command is just mvn deploy to upload the package to ProGet.

It's been quite a while since I last used Maven, but I think the POM file would look something like this:

<project>
...
  <repositories>
    <repository>
      <id>mysite</id>
      <name>My Site - ProGet</name>
      <url>http://www.mysite.com/maven2/mf</url>
    </repository>
  </repositories>
...
  <dependencies>
    <dependency>
      <groupId>apackages</groupId>
      <artifactId>new-packages-jar</artifactId>
      <version>0.0.1</version>
    </dependency>
  </dependencies>
...
</project>

Your template can look like this:

template MakePair<$First, $Second, out @Pair>
{
    set @Pair = @($First, $Second);
}

And the plan that uses the template can look like this:

set @Fruits = @();

call MakePair
{
    First: Apple,
    Second: Orange,
    Pair => @Fruits
}

Hello Glenn,

For now, the “Release Package Triggers” only work with legacy source control providers. It’s certainly on our roadmap to update this module so that there’s a more natural integration point.

But until then, the best solution is to use a changegroup hook in Mercurial, and the Release/Package API. To do this,

1. Create a key at http://buildmaster/administration/api-keys with at least the Grant access to Release & Deployment API box checked.
2. Create a file with the following contents somewhere in the PYTHONPATH of your Mercurial server:

   import urllib
   import httplib
   import json
   
   api_key = 'YOUR_API_KEY'
   app_id = 1
   
   def create_package(ui, repo, **kwargs):
       h = httplib.HTTPConnection('buildmaster')
       h.request('GET', '/api/releases?' + urllib.urlencode({'key': api_key, 'applicationId': app_id, 'status': 'active'}))
       releases = json.loads(h.getresponse().read())
       h.request('POST', '/api/releases/packages/create?' + urllib.urlencode({'key': api_key, 'releaseId': releases[0]['id']}))
       resp = h.getresponse()
       if resp.status != 200:
           print resp.status, resp.reason
           print resp.read()
       else:
           resp.read()
       h.close()
   

3. Add this to .hg/hgrc on the Mercurial server:

   [hook]
   changegroup.buildmaster = python:path.to.create_package
   

Hello Yannick,

Telerik's repository isn't listing the publishing date of the packages, and ProGet is getting confused and assuming that means the packages were never published. This will be fixed in the next version of ProGet (4.7.11) [PG-1019]