Build-Module not working in Azure DevOps Pipeline on ubuntu agent

[af-mst]

Since I struggled like a day with the following problem, so I would like to share my experience. Prob. its not high prio, since there is an easy workaround

Locally I get the correct output under ./Output/MyModule/semVersion/... The .psm1 file contains all the dot sourced private and public functions

When I execute the Build-Module in an Azure DevOps pipeline WITH ubuntu-latest as the agent OS, the .psm1 content is the one with the dot sourcing code, no actual functions:

foreach ($file in Get-ChildItem "private", "public") {
    . $file.FullName
}

Looks like the dot sourcing is not working under ubuntu? 🤔 The PowserShell tasks use all PowserShell Core

Changing the agent OS to windows-latest will solve problem easy. Maybe some ubuntu support would be nice, or at least detect the OS and throw a big bright warning message :)

[bravo-kernel]

@af-mst perhaps you might want to follow an approach similar to this one where the build is done once, on Windows. Tests then can be executed on all other platforms.

https://github.com/alt3/Docusaurus.Powershell/actions/runs/5846483505

[af-mst]

Thats not the point, is it :) But thanks for the example.

I suggest at least an OS warning in the build or minimum an info in the readme of the project. Support on ubuntu/linux would be best, but is not required.

[kilasuit]

I'm pretty sure this does work fine on Ubuntu & macOS build agents.

Do you have a sample pipeline file or build script from the repo that your working on that you can share at all to help in further diagnosis.

[indented-automation]

I read this last night and thought the most obvious problem is that the Linux file system is case-sensitive where Windows is not, that feels like such an easy trap to fall into for the unwary. That's just my first instinct mind you, may be that, may be nothing to do with that.

I have successfully run ModuleBuilder on Linux (Ubuntu, Debian, and CentOS), I run it on Ubuntu in this pipeline:

https://github.com/indented-automation/Indented.Net.IP/blob/actions/.github/workflows/main.yml#L35

Apologies that's a little bit of a convoluted trail in a not-merged branch, (and actions, not AzDo) I lack a decent selection of public artefacts in a reasonable state.

Still, I'd assert that it's not a generalized problem with Ubuntu and something is up with the pipeline in question.

This needs fleshing out with "and here's how you reproduce", or at the very least "here is what I tried". Without this the issue cannot be progressed.

[gaelcolas]

What @indented-automation says :) The DSC community uses Modulebuilder for all of our modules, and I think a good chunk is doing so on Ubuntu latest on AzDO. Don't have times to dig further this month I'm afraid.

[kilasuit]

Thought so too both @indented-automation & @gaelcolas

Example Repo where this is working is StorageDSC which is using Ubuntu-20.04 as the worker as can be seen in this snippet https://github.com/dsccommunity/StorageDsc/blob/00bce03d799c1d31bd16fd605e3882f8ea06226e/azure-pipelines.yml#L21-L47

@af-mst can you take inspiration from that snippet and the build.ps1 in that repo to help you get unstuck here?

Otherwise I think that this can be closed as we have this working in Ubuntu and macOS agents on Azure DevOps ok as per repos that are in use in the DSC Community Organisation.

Feel free to come back to this issue if you need any further help in getting unstuck with this.

[thekamilpro]

So I just encountered this issue, and interestingly, the problem didn't exist on Mac on which I develop, and only manifested itself on Ubuntu-Latest runner.

For now, quick workaround in parameters splat has worked:

$params = @{
    SourcePath = "$PSScriptRoot/source/fred.psd1" 
    UnversionedOutputDirectory = $true
    Version = $Version 
    Passthru = $true
    Verbose = $true
    OutputDirectory = "$PSScriptRoot/build/fred"
    SourceDirectories = @("public", "private")
    PublicFilter = "public\*.ps1"
}

[af-mst]

For me its resolved due to the case-sensitivity... I configured the respective directories and it started working, sorry to bother anyone :)

[Jaykul]

Yeah, I hit this a couple of times this week. The MacOS is not case-sensitive for directories, so usually when you run into this it's because you used "public" and "private" folders when ModuleBuilder's SourceDirectories defaults to "Enums", "Classes", "Private", "Public" with capital letters.

Frankly, I still like having those capitalized, but it's annoying that the defaults are case-sensitive (except of course, they aren't, it's Linux that's case sensitive).

I've been looking at how to make them not case sensitive, and I think the best bet is to support wildcards in that parameter. I mean, I don't think anyone's really going to use wildcards there, unless they just put "*" or "p*" or something ... but the wildcard support would let us use [Pp] in place of P so we could set the default to "[Ee]nums", "[Cc]lasses", "[Pp]rivate", "[Pp]ublic"