Hello,

We just did a massive docs migration, and our marketing team is monitoring for these missing pages.

Here is the correct page: https://docs.inedo.com/docs/inedoagent/installation/installation-guide

Hope this helps,
-John

@ssuenaga_1020 said in PyPI upload endpoint:

curl https://{proget}/pypi/Python/upload --user <user>:<password> --upload-file <file-path>

Sorry about that, it appears the actual upload URL is:

curl https://{proget}/pypi/Python/upload/<packageName-version.tar.gz> --user <user>:<password> --upload-file <file-path>

I will update the documentation to reflect this on both the website and in the software.

Thanks,
-John

I fixed this incidentally in this commit: https://github.com/Inedo/inedox-git/commit/325562db2ea5996a1dc559f5997dca49cc9452df

The fix is available as of v1.3.1 of the Git(Hub|Lab)? extensions :)

Hi Mark,

This bugfix will be included in v6.1.11 due out this Friday. Thank you for your patience.

Thanks,
-John

Hi David,

It's a bit verbose, but you should be able to get away with something like this:

##AH:UseTextMode
module CheckBuildCriteria<out $validBuild>
{
    set $validBuild = false;
}

call CheckBuildCriteria
(
    validBuild => $IsValidBuild
);

try
{
    if !$IsValidBuild
    {
        Log-Error Build criteria is invalid...;
        throw;
    }
    
    # normal plan operations go here...
}
catch
{
    if !$IsValidBuild
    {
        force normal;
    }
}

Aha, it will also be included in BuildMaster... not sure why I got stuck on Otter. I guess it was on my mind because we just had a maintenance release today :)

This feature is also scheduled for BuildMaster v6.1.10 on July 19

Hi Philippe,

I know it's been a while since this question was posted, but just wanted to let you know that we will soon be supporting the behavior in Otter of allowing multiple resource credentials of the same name that differ only by environment.

We are still in the process of determining the UI (e.g. allowing selection of multiple environments at once) but at least the core functionality you described will work.

This is being targeted for Otter v2.2.5 due out July 26.

Hope this helps,
-John

Hi David,

You can view the results of a monitor that triggers a plan in the Admin > Executions page, filtering by "Build Trigger".

You can also add some hack debugging to the plan that logs the built-in monitor variables to a file so you can see if it's triggering.

If it's still not triggering, try configuring the monitor to a public instance of something on GitHub like https://github.com/Inedo/git-test.git to see if that works since GitHub supports the SVN protocols as well.

Hope this helps,
-John

Resolved via ticket:

If you want to call PowerShell functions, you need to wrap them in a PowerShell Module, then import that module in your PowerShell script asset. That's the only way I can think of that this will consistently work. I've implemented something like this before:

set $ModuleName = Hello-World;
Get-Asset $ModuleName.ps1
(
    Type: Script    
);
set $ModulePath = $PathCombine($WorkingDirectory, $ModuleName.ps1);

PSEnsure
(
    Key: Test,
    Value: True,
    Collect: "$false",
    Configure: >>
    Import-Module -Name "$ModulePath" -Verbose
    
    Hello-World "Testing 123"
    >>
);

which just writes a Hello-World script out and imports it as a PS module. You could probably figure out a better way than this e.g. creating a "PsModule" role that ensures the module is installed on any servers you're working with, then you'd only need the Import-Module command in your scripts to gain access to all your shared functions.

Apologies, I had seen the StackOverflow post first, so I responded here: https://stackoverflow.com/questions/56338757/proget-symbols-and-source-server-download-pdb-correctly-but-source-not-found/56397293#56397293

Typically this is caused by a Windows extension that hasn't been updated to the latest version following a BuildMaster v6 upgrade.

In what context would this protocol be used? My understanding is that BITS is used for background/asynchronous transfers, and in the common Otter use-case, the package needs to be available on the server in order to progress through a configuration plan, therefore the only benefit I can see is the network throttling.

FYI this has been added (in Subversion extension v1.1.0) and the available variables are documented here: https://inedo.com/support/documentation/buildmaster/builds/continuous-integration/source-control/svn#automatic-builds-continuous-integration-with-subversion

Hi Patrick,

As of ProGet v5.2, we have a new Management API that makes this much simpler.

I've added a Configure Retention example to the Update Entity docs here that shows how to add retention rules: https://inedo.com/support/documentation/proget/reference/api/feed-management#update

This was an oversight, we'll add this ASAP. The tracking issue is: https://github.com/Inedo/inedox-subversion/issues/3

I actually added this but it wasn't released as part of the beta; it will be an option in the Status filter e.g. "Agent error", "Collect/remediate error", and "Any error"

I'm not sure why that response says that (I believe it was written when ProGet was still in Beta), but it is in fact inaccurate.

The rules for closed testing or DR instances is that a separate license is required as per the licensing agreement: https://inedo.com/proget/license-agreement

In order to clarify this with some examples, I've added the following documentation that will release when 5.2 goes live:

https://github.com/Inedo/inedo-docs/blob/proget-5.2/ProGet/administration/license.md#examples

Thanks for the suggestion, I've filed this to be done here: https://github.com/Inedo/inedox-inedocore/issues/112

The problem is that OtterScript attempts to parse those variables first. Just use quotes:

set $foo = true;
set $bar = true;
set $foobar = $PSEval("$foo -and $bar");

Log-Information `$foobar = $foobar; # prints: $foobar = True

This appears to be a bug with the ProxyRequest property, i.e. if it's true (the default), the response variable is not set.

The tracking issue for this is here: https://github.com/Inedo/inedox-inedocore/issues/91