@philippe-camelio_3885 oh i see; you mean, capture the output of a process or script execution into a variable or something. Definitely something to consider as an enhancement, I think. That wouldnt' be too bad (though the variable could get huge, and rutnime variables raen't realy designed for large amounts of text like that)

Ok Thanks for the reply

Hey @atripp I know this is still a beta. Happy to help you Philippe

@Joshua_1353 did this work in Otter v2? The "too many redirects/auth requests" is usually a kind of red herring, and refers to some sort of configuration problem (corrupt local repository, cached credentials, etc.). We'd need to see the whole stack trace --- but could you post it to a new Topic, so we can track it differently? I don't think it's related to v3. The reason it didn't show in v3 was (we just forgot to tag it properly after some coding refactoring changes in Otter).

I had such problem with localized account with a lot of software :) Managing the [Otter / Buildmaster / Proget] service Account from the InedoHub would be nice. Philippe

Thanks for the update; and the upcoming fixes will certainly make it so that purging is much more efficient on the manual execution side, just in case there's an "Explosion" of executions like this. So right now, my concern is that it's "logging every sync" (once per hour), due to a sort of bug or something. Can you check what's getting logged in Infrastructure Sync? You should be able to see this under Admin > Executions, and see if you can spot a pattern? No rush. The infra sync executions should clearly show a change history of what was updated on the infra side.

@philippe-camelio_3885 FYI, we will add a checkbox for auto-purging soon, BM-3655

You're welcome

Hi Phillipe, I created an issue on GitHub, #8, to track adding this to the extension. I'll reply back once there is a CI version released of the extension. Thanks, Rich

@atripp Good news Thank you

Thanks for the fast resolution

@gdivis

@rhessinger Thanks a lot. I will try it.

In my opinion, using $ApplicationName is not possible, at least for Gitlab Indeed from GitLab ref, we read : The URL a badge points to, as well as the image URL, can contain placeholders which will be evaluated when displaying the badge. The following placeholders are available: * %{project_path}: Path of a project including the parent groups * %{project_id}: Database ID associated with a project * %{default_branch}: Default branch name configured for a project’s repository * %{commit_sha}: ID of the most recent commit to the default branch of a project’s repository As %{project_path} is different from $ApplicationName if the project is defined in a group, the only link between the gitlab project and the builmaster application is the commit_sha var. I think you just need to add stage as querystring and make the search for the result of the pipeline named stage for which exists an active build variable ($commitId in my example) with a value of commit_sha. and $commitId has to be unique over all BuidMaster. Actually, it is not possible to get more variables (ideally %{project_path} at the GitLab::Get-source step. The filter would be then better (Filter for project_path+ commitid + stage), but this is still a build variable and not an implicit variable like $ApplicationName I don't know if there a better way because I have just started to use Gitlab.

@atripp Thanks

I switch to a domain account and it works ... Small bug I guess Thanks for the fast reply

@atripp Thank you Just one small quesiton: When do you plan to make the UPack raft available for both BuildMaster and Otter ?

Hello @atripp You were right. In Otter Define the agent's temp directory as it should be by default /tmp/otter. In BuildMaster Force a sync Infrastructure The pb is gone I will now implant my ansible function on buildMaster Best Regards PhilippeC.

@rhessinger Good news thank you