resolve multi repo dependencies for localdevenv.ps1

[KristofKlein]

Is there a "good way" to resolve dependencies for a multi repo setup while using the localdevenv.ps1 scripts from Al.Go? Maybe I do just miss a setup?! Pipelines/Workflows do get the job done, but not the script. Flows are setup to produce NuGet packages. I could make use of them as well while local dev, but there I would first need to also analyze what is potentially missing?

[freddydk]

If you setup GitHubPackages for internal dependency resolution - this should work with localdevenv as well.
I would think NuGet would work as well - but I haven't tested.

[curateideas]

We had an issue when gh CLI was introduced. First, our developer didn't have it installed. Second, no rights were assigned for a team of users to the corresponding repos. After fixing both, localdevenv worked.

As we already discussed: org-settings and mainting teams in GitHub make it a lot easier to use AL-Go for GitHub.

[KristofKlein]

Yes, the missing installation I trapped also into, but that was minor to resolve but is on the "todo list for new machines or developers that will jump to github" (again something to mentioned in the getting started documentation). The missing rights is - for me - a topic on it's own.... but I can pull it all down to a REPO setup ( thanks to the inheritance in Al:Go) and have it under "my control".

I need to find a better common ground on this, as it will end up in a lot of cases "works on my machines". If a "Service PAT" should exists in the context of dependency downloads for local dev ... I would say no. And if I read it in the al:go code right, it should fall back to "gh auth token" anyway. And that is what I would like it to be. (which all goes hand in hand with what you wrote: make the setup right).

So I will stick to the appDependencyProbingPaths for now. However, not setup in GitHub variable ALGOORGSETTINGS but in my repo AL-Go-Settings.json.

[KristofKlein]

Not yet over the finish line! So, Besides the text saying: will make use of gh auth token, I have the feeling this is not correctly in place. I have setup appDependencyProbingPaths excluding a token variable. So I get the text above. but while running I see the correct URL, followed by a 404...
It looks like it does not use gh to get the releases ( which is not even possible i think!?) so fair enough, it makes use of api.github via an invokeWebRequest ... could it be that it never sets the token in such a request scenario @freddydk ? I see at least two Write-Host "gh auth token" but never a $token = gh auth token (e.g. function CheckAppDependencyProbingPaths, has this if ($token) {...} else {Write-Host ..} i think there it misses a $token = gh auth token} )? While the second might goes into invoke-gh and does the token thing implicit.... but pretty sure the API call is missing int...

Because if I set my token (either a self-made ghp_ or the gho_ from gh auth token) the request works just fine. But I don't want to share/set tokens If I don't have to. (actually I also changed the temp ps1 file with what I mentioned earlier, and it passes and downloads now the needed dependencies)

[freddydk]

I think I was in vacation mode. Will look into this next week.

[KristofKlein]

Well, according to my very limited view on things, I might still believe you are one of the persons that totally deserves vacation....Not too often! Nono, but once in a while is definitely ok.
Fun aside :) All good, I am still on square one with all this, I just found out, I have a lot to catch up, and not everything is clear on first sight (documentation could use some love :P ) Especially the fact that this is "PTE/SaaS" not OnPrem (which is totally fine) - while I want to make it run for OnPrem as good as I need it for now. And it does not need too much to make it behave, so well done and thanks for all the "hooks" everywhere.
You know, I wanna go "all in" on Al:Go. so besides understanding I also have other work to do: like move, rename and merge given mono App Repos into MultiApp Project Repos, persist the history, throw aboard our old container scripts, explain this to developers and many more steps in between. It's just a bit overwhelming :) And I have no problem to wait for some answers - there is other areas that needs attention as well ;)