Well, the NuGet API version is totally unrelated; and regarding the v3 API, it's still not stable/public yet, but they are planning a stable/public API at some point in the future (no ETA). Regarding SemVer v2 support for NuGet packages/feeds, tut The NuGet team reports they may support it in v3.5 or v3.6; if/when that happens, we'll add support for it in ProGet's NuGet feed.

Nice read, I just passed this onto a friend who was doing some research on that. And he actually bought me lunch as I found it for him smile Thus let me rephrase that Thanks for lunch! bagkeecdckkdedbb

Hello; I believe the error is due to a bug in the LdapDirectory code, which is not properly escaping that group name that has a parenthesis in it. So, we will need to fix the bug; I've logged this as PG-602, and we can get it in the next maintence release (which is targeted for next week). Best, Steve

Ok, so I have now got something working. It seems it was failing because I had the smaller installer (without sql server). That does absolutely nothing when running the silent command. If that's meant to be the case, then maybe that should be documented somewhere. Thanks

Alana, thanks. Just getting into using the script and didn't realize I could create a var with no value like that. Thanks!

Is there anything listed on the Administration > Error Log page that relates to this? Errors listed there will have additional context (feed, connector, etc) If it doesn't appear there, I guess you could enable 1 at a time to see which one is the culprit.

I actually am at fault for not being thorough here; I jumped in without being diligent. I am not using Integrated, but using LDAP provider via forms in Buildmaster and it was this that was failing. My apologies! Our custom OAUTH API gateway validates against ADFS prior to providing tokens, think of it as a custom Oauth2 token provider to provide SSO with Windows Auth. The whys and hows can be discussed offline if you want, though there are a few sites which explain this and the reasonings. This custom OAUTH Api/gateway worked at the time of Buildmaster not working. Hence my confusion about why one was working and not the other. With that said, I will still continue to monitor. I will assume this was a "fluke" on the system side that is not worth troubleshooting.

Ah yes, that solved my problem. Thanks!

Unfortunately we're not able to diagnose this with the information you provided. That error really doesn't make sense in the place it's happening. Can you please submit a ticket with: Configuration Variables defined at various levels (System, etc) Plan as OtterScript Pipeline as JSON Full Execution log, including the full stack trace you sent

Yep, all of these are things that people use BuildMaster for on a regular basis. Note that, the terminology you're using ("pipelines") is more generalized than the BuildMaster construct (there are Pipelines and Deployment Plans that do a mix of the things you describe), but the general idea is the same.

It's supported using the Legacy Action, which isn't ideal obviously. This will be replaced with a function in v5/OtterScript: # reads at most 250 characters from the file set $hdarfs = $FileContents(c:\hdarfs\info.txt, 250); Log-Information $hdarfs; However, this function is only available in 5.3 (which is shipping this week).

Alana, I knew they are in the legacy side but I couldn't find a easy way to find/use them if I'm creating a new plan but I didn't think of creating a new legacy one then converting it later (firm smack to my forehead!) Thanks!

Whoops, seems like we forgot to update the operations documentation on the site after 1.3. The function is renamed to $GetCredentialProperty (though the old alias should still work) and you can access it like: <code>set $password = $GetCredentialProperty(MyCredential,Password);</code> Note you can see the generated documentation: http://<otter-host-name>/reference/functions

Currently, only NuGet feeds use the license filter, it shouldn't be displayed on npm feeds... We do plan on adding support for better licensing filtering in a future version, as the current implemention is a bit limiting.

Thanks for the pointer. I noticed if I edit the Job Template it doesn't seem to have the right plan 'selected' in the Plan Name dropdown (it defaults to the first in the list every time). I think I saved it without noticing and it ended up attached to the wrong one. Maybe review the edit code that generates this page: https://url/job-templates/edit?jobTemplateId=x

We do, along with a few other types (Gems, PyPi, Composer), but there's no ETA on it right now; once we get private a Docker registry, we will look to refactor the feeds and UI a bit as to allow for easier adding of simple package types.

The "Generate Release Notes Action" in those release notes was referring to the same action as 4.9.7, which was not implemented in 5.0.0. The Generate Release Notes Operation for v5 plans is available as of v5.2.3.

Chocolately packages are, essentially, nothing more than a powershell script that downloads and runs an installer from some url on the internet. It would be virtually impossible to inspect arbitrary powershell scripts and determine what they would download when run, and then download/proxy those installers. So, if you want full control over all aspects of the chocolatey packages (including the installers that are downloaded), you will just have to create your own based on the contents of the open-source packages.

Hi Alana, Any chance of sending that C# code to me as well? We are also facing issues getting multi-domain AD working. TIA

Sorry for a late follow up on this. So one place where this solution falls apart is that your Jenkins add-on for BuildMaster does not support the meta-tags in the version field.