🪲[Bug]: LogGroup function source and variable scoping in LogGroups

[vercellone]

Describe the bug

I've forked your GitHub repo intending to contribute some Codespace and Secret functions and am having difficulty building it locally to test my new functions before pushing anywhere.

1. Build-PSModule depends on LogGroup which is not defined in this repo nor the Utilities module. Set-GitHubLogGroup has a LogGroup alias, so I assume that is the intended function here.
   1. Perhaps you should have a default implementation of LogGroup inside Utilities.
   2. Or, alternatively, you could fully qualify LogGroup as GitHub\Set-GitHubLogGroup.
2. Functions and variables defined inside of LogGroup scriptblocks go out of scope and are not defined unless I dot-source the LogGroup call itself.

Version information

Name                           Value
----                           -----
PSVersion                      7.4.6
PSEdition                      Core
GitCommitId                    7.4.6
OS                             Microsoft Windows 10.0.26100
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     0.2.2                 Utilities                           Core,Desk {ConvertFrom-Base64, ConvertFrom-Base64String, ConvertTo-Base64, ConvertTo-Base64String…}

And, latest main branches of Build-PSModule and GitHub.

To reproduce

Try to use Build-PSModule locally to build GitHub in a fresh environment.

Code snippet

Build-PSModule -modulename GitHub -Modulesourcefolderpath 'D:\src\github\GitHub\src' -ModulesOutputFolderPath 'D:\src\github\GitHub\out' -DocsOutputFolderPath 'D:\src\github\GitHub\outdocs'

Relevant output

::group::Building module [GitHub]
Source path:          [D:\src\github\GitHub\src]
Module source folder: [D:\src\github\GitHub\src]
Module output folder: [D:\src\github\GitHub\out\GitHub]
Docs output folder:   [D:\src\github\GitHub\outdocs]
::endgroup::
Build-PSModule [main ≡ +0 ~2 -0 !]                                                                                                                                                    0d 0:00:00.0652 08:05:49 PM
0012
Build-PSModuleBase: D:\src\github\Build-PSModule\scripts\helpers\Build-PSModule.ps1:50:68
Line |
  50 |  … oduleName $ModuleName -ModuleSourceFolder $moduleSourceFolder -Module …
     |                                              ~~~~~~~~~~~~~~~~~~~
     | Cannot bind argument to parameter 'ModuleSourceFolder' because it is null.

[MariusStorhaug]

Hey Jason,

Great! You’d be the first contributor on the GitHub module.

The plan is anyways to remove the LogGroup implementation in Utilities and add a #Requires statement where it is needed towards the GitHub module. You don’t see it loaded here as it happens in the GitHub action call itself using the PSModule/GitHub-Script action. Plan longterm is packing up the module framework as a module, but not there yet.

I am also gradually splitting out the Utilities module to own modules that are named based on what they cover. So I’d rather put less dependency on that.

However to the scoping issue you’re seeing. This is the first time I see it fail, as all usage of it so far in GH action work without issues. So not sure what the difference is. Any idea?

[MariusStorhaug]

On the note about LogGroup it is now removed from Utilities:
Release v0.3.0 · PSModule/Utilities

Running tests here now to verify.

[MariusStorhaug]

Feel free to open a PR anyhow to the GitHub repo. If its no problem from your end, please make them separate. One for Codespaces and another for secrets. I need secrets too soon so eager to see what you have. Also please open issues on it so that I know the scope of your work. I need to automate providing secrets on organizations first. But guess its the same dependency we need (libsodium).

[MariusStorhaug]

Updated the file requirements so that we have the correct reqs for each file. Sorry, but this is not optimized on running locally for testing functionality. :)

• 🩹 [Patch]: Fix #Requires statements on all script files Build-PSModule#93

[vercellone]

about_Scopes

I suspect the following bit is the key factor for usage in GitHub actions.

Functions from a module don't run in a child scope of the calling scope. Modules have their own session state that's linked to the scope in which the module was imported. All module code runs in a module-specific hierarchy of scopes that has its own root scope. For more information, see the Modules section of this article.

As you say, it is not optimized on running locally. I can work around it, but I think there's a lot of room for improvement for future contributors.

[vercellone]

Check out PSModule/Sodium#10. In the meantime, I'll work on a GitHubSecret PR that assumes ConvertTo-SodiumEncryptedString is defined elsewhere.

[MariusStorhaug]

@vercellone Not sure if this was partially solved with the cleanup in Utilities and the rest is the script you are building for local testing?

[MariusStorhaug]

Closing as its stale + think it not something I'd fix as its running fine in a runner. Will get this fixed when working on the "local dev story".