Discussion: Add / validate support for Linux / MacOSx about psclassutils HOT 29 OPEN

Suggesting two ways.

1. Use multiple environments in the same .yml file
   https://www.appveyor.com/docs/build-environment/#using-multiple-images-for-the-same-build
   With these build options.
   https://www.appveyor.com/docs/linux-images-software/
2. One continuous build using several tag systems to focus one platform at a time.
   https://www.appveyor.com/docs/build-configuration/

from psclassutils.

I think that's a very good idea.

I guess we could take the same Tests and just run them on other (Gitlab Term) "Runners". Don't know how they are called on appveyor ^^

I would also see this as a possibility to change the CI to a build Script to clean up the yml file.

from psclassutils.

I had to make one small correction to get the module to load on Linux. I didn’t actually test anything on it.

Have you looked at Azure DevOps for CI? You get Windows, Linux and MacOS testers.

I have a project I’ve started and I run the same scripts to test all three platforms.

I’ll do some testing in the next few days and see how it goes.

from psclassutils.

Thanks for your feedback guys 👍 !

Indeed @bateskevin redoing the CI is something that I wanted to do anyways. It make sense to do that now.
I like your ide of @PeterMTaylor having the same .yml file for each envionment.

If I summarize our thoughts up until now:

0. Only one minor change was needed according to @tigerfansga (Could you let us know what exactly? 🌈 )
1. Update the CI
2. Add multiple environments to the CI
3. I have created a seperate branch for this Here
4. Anything else?

I do have something localy for another test repo, which I can reuse and combine. I'll take this one, and start working on it immediatley, and come back here to share my progress and ask for your valuable feedback 🦄 😸

from psclassutils.

This change was required for the module to load. The issue stems from the case sensitivity of the Linux file system -

diff --git a/PSClassUtils.psm1 b/PSClassUtils.psm1
index 00d2975..cde1648 100644
--- a/PSClassUtils.psm1
+++ b/PSClassUtils.psm1
@@ -15,7 +15,7 @@ foreach ($Private in $PrivateFunctions){
 }
 
 write-verbose "Loading Public Functions"
-$PublicFunctions = gci "$ScriptPath\Functions\public" -Filter *.ps1 | Select -Expand FullName
+$PublicFunctions = gci "$ScriptPath\Functions\Public" -Filter *.ps1 | Select -Expand FullName
 
 
 foreach ($public in $PublicFunctions){
 [issue-15 ≡]

I ran your pester tests on my laptop, there were a lot of failures. Looks like something you use is either not available on PowerShell core or needs to be reworked. I will do some investigations. I've attached the output file from the pester run.
test.txt

from psclassutils.

I'm fairly new at this CI stuff for PowerShell, I created a HelloWorld project to experiment with. I've not gotten to the publishing piece, and I've pulled together things I've seen on other projects.

from psclassutils.

I've found another issue, it just didn't throw an error till I loaded with -verbose

> import-module ./PSClassUtils.psd1 -Verbose
VERBOSE: Loading module from path '/home/mark/Documents/Projects/PSClassUtils/PSClassUtils.psd1'.
VERBOSE: Loading module from path '/home/mark/Documents/Projects/PSClassUtils/PSClassUtils.psm1'.
/usr/bin/sort: cannot read: Name: No such file or directory

In pscore they don't created aliases that cover native commands - so my guess is changing sort to sort-object will fix most of the issues. I will try later

from psclassutils.

Changing sort to Sort-Object was the trick. Now only 8 Pester tests fail. Best I can tell all are related to PSGraph not looking for graphviz where it got installed - I think it is an easy fix, and will do some testing and either open an Issue or PR to that project.

Here is the updated git diff

> git diff master issue-15 -- ./PSClassUtils.psm1                       
diff --git a/PSClassUtils.psm1 b/PSClassUtils.psm1
index 00d2975..a487938 100644
--- a/PSClassUtils.psm1
+++ b/PSClassUtils.psm1
@@ -15,7 +15,7 @@ foreach ($Private in $PrivateFunctions){
 }
 
 write-verbose "Loading Public Functions"
-$PublicFunctions = gci "$ScriptPath\Functions\public" -Filter *.ps1 | Select -Expand FullName
+$PublicFunctions = gci "$ScriptPath\Functions\Public" -Filter *.ps1 | Select -Expand FullName
 
 
 foreach ($public in $PublicFunctions){
@@ -27,7 +27,7 @@ foreach ($public in $PublicFunctions){
     }
 }
 
-$PrivateClasses = gci "$ScriptPath\Classes\Private" -Filter *.ps1 | sort Name | Select -Expand FullName
+$PrivateClasses = gci "$ScriptPath\Classes\Private" -Filter *.ps1 | sort-object Name | Select -Expand FullName
 
 
 foreach ($Private in $PrivateClasses){

I've also attached the latest Invoke-Pester results test.txt

from psclassutils.

A simple correction on PSGraph to find graphviz and it's down to two test failed. I'll open an issue on the PSGraph project and see if Kevin wants to fix it or if I can do a PR for it.

Attached is my current Invoke-Pester run. I'm going to watch football the rest of the day I think. 😁
test.txt

from psclassutils.

Hey @Stephanevg

Would you mind if I submitted a PR to make the changes listed above. I'm needing two more PR for #hacktoberfest

from psclassutils.

from psclassutils.

Will do that.

from psclassutils.

PR #43 submitted. All but 3 Pester tests are now passing on Linux. All three tests that are failing are in Tests/ClassUtils.Write-CUClassDiagram.Tests.ps1. The $b -cmatch '"Woop" \[label=.*' | should Not beNullOrEmpty check fails on each.

The commands being tested are working, the output just doesn't match the regular expression. I will need to do some testing on Windows to compare the output to see what isn't working.

from psclassutils.

thank you so much for your PR @tigerfansga I just merged it in dev. I will update the CI part to have a build on linux as well, and merge it when everything is green there as well.

Concerning your issues with the 3 remaining pester tests. There are perhaps a few things you can look into (If you want of course :))

For some reason, I have the impression this is a casesensitivty thing, again .

there are some hints that could (maybe) spot the issue:

We can add ignore case in the call, to force the cmdlet to completley ignore the casing (this forces everything to lowercase actually) (note also, I lowered cased the w from the cmatch.

1. $b = Write-CUClassDiagram -Path $FolderPathFolder -PassThru -IgnoreCase
   $b -cmatch '"woop" [label=.*' | should Not beNullOrEmpty

2. leave everything as is, but replace -cmatch with -match.

You could look into the variable $b (simply output it to the console) and you will see the string that it contains. Somewhere, it should contain Woop [label= . If not, then there is another problem somewhere in the cmdlet it self, instead of just the test (which I doubt, since you seemed to say, that the cmdlet runs correctly, and creates graphs, right?)

Cheers

from psclassutils.

Actually, my first thought was a case thing but I ran basically manually did the tests and there was output that looked valid but didn't have anything close to matching the regular expression. I got a memory upgrade for my laptop and will be able to run a windows vm. I will run a similar test and compare the output between the two platforms to see. I'm just not familiar enough with what the output looks like when run on windows to make a judgement.

from psclassutils.

Progress. I was able to setup a windows VM on my laptop to do some testing. Working with the current master branch, I was able to get everything setup and run the Pester tests.

On Windows PowerShell, all tests pasted as expected. On PowerShell Core, two of the tests with that are failing on Linux also fail. So there is some kind of behavior change between Windows PowerShell and PowerShell core. I will research more later.

from psclassutils.

great! i have the impression we are close to complete this one!
could you share a screen shot of the failing tests? Perhaps we can help resolving it (or at least identify the problem)

from psclassutils.

I will run the test manually and post the output

from psclassutils.

Ok, I've recreated the issue. Ultimately, it looks like somethings are getting ordered differently breaking the regex. It definitely looks like an issue with the test and not the actual code.

So I created a file sample\class.ps1 with the following contents

    Class Woop {
        [String]$String
        [int]$number
    
        Woop([String]$String,[int]$Number){
    
        }
    
        [String]DoSomething(){
            return $this.String
        }
    }
    
    Class Wap :Woop {
        [String]$prop3
    
        DoChildthing(){}
    
    }
    
    Class Wep : Woop {
        [String]$prop4
    
        DoOtherChildThing(){
    
        }
    }

Then on Windows, I ran the following command in both Windows PowerShell and PowerShell Core
Write-CUClassDiagram -Path .\sample -PassThru

In Windows PowerShell here is the output

digraph g {
    compound="true";
    subgraph cluster79ae6720cad0 {
        label="class.ps1";
        "79ae6720cad0" [label="";style="invis";shape="point";]
        "Woop" [label=<<TABLE CELLBORDER="1" BORDER="0" CELLSPACING="0"><TR><TD bgcolor="black" align="center"><font color="white"><B>Woop</B></font></TD></TR><TR><TD PORT="Row_String" ALIGN="LEFT">+ [String] $String</TD></TR><TR><TD PORT="Row_number" ALIGN="LEFT">+ [int] $number</TD></TR><TR><TD PORT="Row_Separator_Constructors" ALIGN="LEFT">-----Constructors-----</TD></TR><TR><TD PORT="Row_Woop" ALIGN="LEFT"> Woop([String]$String,[int]$Number)</TD></TR><TR><TD PORT="Row_Separator_Methods" ALIGN="LEFT">-----Methods-----</TD></TR><TR><TD PORT="Row_DoSomething" ALIGN="LEFT">+[String] DoSomething()</TD></TR></TABLE>>;fillcolor="white";shape="none";style="filled";penwidth="1";fontname="Courier New";]
        "Wap" [label=<<TABLE CELLBORDER="1" BORDER="0" CELLSPACING="0"><TR><TD bgcolor="black" align="center"><font color="white"><B>Wap</B></font></TD></TR><TR><TD PORT="Row_prop3" ALIGN="LEFT">+ [String] $prop3</TD></TR><TR><TD PORT="Row_Separator_Constructors" ALIGN="LEFT">-----Constructors-----</TD></TR><TR><TD PORT="Row_Separator_Methods" ALIGN="LEFT">-----Methods-----</TD></TR><TR><TD PORT="Row_DoChildthing" ALIGN="LEFT">+ DoChildthing()</TD></TR></TABLE>>;fillcolor="white";shape="none";style="filled";penwidth="1";fontname="Courier New";]
        "Wep" [label=<<TABLE CELLBORDER="1" BORDER="0" CELLSPACING="0"><TR><TD bgcolor="black" align="center"><font color="white"><B>Wep</B></font></TD></TR><TR><TD PORT="Row_prop4" ALIGN="LEFT">+ [String] $prop4</TD></TR><TR><TD PORT="Row_Separator_Constructors" ALIGN="LEFT">-----Constructors-----</TD></TR><TR><TD PORT="Row_Separator_Methods" ALIGN="LEFT">-----Methods-----</TD></TR><TR><TD PORT="Row_DoOtherChildThing" ALIGN="LEFT">+ DoOtherChildThing()</TD></TR></TABLE>>;fillcolor="white";shape="none";style="filled";penwidth="1";fontname="Courier New";]
    }

    "Woop"->"Wap" 
    "Woop"->"Wep" 
}

In PowerShell core

digraph g {
    compound="true";
    subgraph cluster5b749264ca28 {
        label="class.ps1";
        "5b749264ca28" [label="";shape="point";style="invis";]
        "Woop" [shape="none";penwidth="1";fillcolor="white";label=<<TABLE CELLBORDER="1" BORDER="0" CELLSPACING="0"><TR><TD bgcolor="black" align="center"><font color="white"><B>Woop</B></font></TD></TR><TR><TD PORT="Row_String" ALIGN="LEFT">+ [String] $String</TD></TR><TR><TD PORT="Row_number" ALIGN="LEFT">+ [int] $number</TD></TR><TR><TD PORT="Row_Separator_Constructors" ALIGN="LEFT">-----Constructors-----</TD></TR><TR><TD PORT="Row_Woop" ALIGN="LEFT"> Woop([String]$String,[int]$Number)</TD></TR><TR><TD PORT="Row_Separator_Methods" ALIGN="LEFT">-----Methods-----</TD></TR><TR><TD PORT="Row_DoSomething" ALIGN="LEFT">+[String] DoSomething()</TD></TR></TABLE>>;style="filled";fontname="Courier New";]
        "Wap" [shape="none";penwidth="1";fillcolor="white";label=<<TABLE CELLBORDER="1" BORDER="0" CELLSPACING="0"><TR><TD bgcolor="black" align="center"><font color="white"><B>Wap</B></font></TD></TR><TR><TD PORT="Row_prop3" ALIGN="LEFT">+ [String] $prop3</TD></TR><TR><TD PORT="Row_Separator_Constructors" ALIGN="LEFT">-----Constructors-----</TD></TR><TR><TD PORT="Row_Separator_Methods" ALIGN="LEFT">-----Methods-----</TD></TR><TR><TD PORT="Row_DoChildthing" ALIGN="LEFT">+ DoChildthing()</TD></TR></TABLE>>;style="filled";fontname="Courier New";]
        "Wep" [shape="none";penwidth="1";fillcolor="white";label=<<TABLE CELLBORDER="1" BORDER="0" CELLSPACING="0"><TR><TD bgcolor="black" align="center"><font color="white"><B>Wep</B></font></TD></TR><TR><TD PORT="Row_prop4" ALIGN="LEFT">+ [String] $prop4</TD></TR><TR><TD PORT="Row_Separator_Constructors" ALIGN="LEFT">-----Constructors-----</TD></TR><TR><TD PORT="Row_Separator_Methods" ALIGN="LEFT">-----Methods-----</TD></TR><TR><TD PORT="Row_DoOtherChildThing" ALIGN="LEFT">+ DoOtherChildThing()</TD></TR></TABLE>>;style="filled";fontname="Courier New";]
    }

    "Woop"->"Wap" 
    "Woop"->"Wep" 
}

The line that is causing the issue in the test is this
Windows PowerShell
"Woop" [label=<<TABLE CELLBORDER="1" BORDER="0" CELLSPACING="0"><TR><TD ...

PowerShell Core
"Woop" [shape="none";penwidth="1";fillcolor="white";label=<<TABLE CELLBORDER="1" ...

from psclassutils.

I suggest making the following change to the test regex (it appears 3 times) from $b -cmatch '"Woop" \[label=.*' | should Not beNullOrEmpty to $b -cmatch '"Woop" \[.*label=.*' | should Not beNullOrEmpty

Can probably make the regex a little tighter but I'll start with that.

Also, had a new file system case issue pop up from the CI restructuring. It only effects the tests actually, but I'll work it into the next pull request.

from psclassutils.

I've submitted PR #44 to correct these issues. I ran Pester test locally on Linux and Windows (Windows PowerShell and PSCore). This should get the module in good shape.

I do have access to a MacOS machine and will test in the next week.

from psclassutils.

wow, @tigerfansga ! I wasn't expecting that level of detail, great work!

I have merged your branch into dev, and will shortly add it into master.

I still think it is a bit strange, that the psgraph returns another graph result on linux.

Have your tried running the following command on linux?

#sample.ps1 contains the classes from the example in the discusion above
Write-CUClassDiagram -Path .\sample.ps1 -show

theoretically, it 'should' create the following output (Except the title of the graph is called 'inheritence' here, but it should be sample.ps1:

if not, we have a little bit more work on the write-CUClassDiagram to do to make it 'linux friendly' then what I originally thought.

from psclassutils.

I have updated our CI on this project now. From now on, we will have a build on Windows, and linux each time we push a commit to one of the branches. I think @tigerfansga might find this usefull 😉
The latest build results on linux are available here : https://ci.appveyor.com/project/Stephanevg/psclassutils/build/job/hxvagfmrr4rkq55g (Please let me know if this link work for your guys).

I could see we have some issues with the packageProvider, and one pester test failing for Write-CUClassDiagram. @tigerfansga have you seen this one before?

from psclassutils.

Actually, the difference is Windows PowerShell verse powedhell core. The output was all windows. I think the graph actually is the same, just things ordered differently.

from psclassutils.

Hi @tigerfansga
I know this has been a while, but, I am facing some issues with generating Graphs on my Ubuntu machine. (Graphviz cannot be found by the module).
You wrote above:

A simple correction on PSGraph to find graphviz and it's down to two test failed. I'll open an issue on the PSGraph project and see if Kevin wants to fix it or if I can do a PR for it.

Do you remember what you did to fix it ?

from psclassutils.

Hi @tigerfansga I actually got around, and found your PR KevinMarquette/PSGraph#78 , which seems not be applied in version 2.1.33.

We are one failing test away from closing this issue :)

from psclassutils.

Tracking the last issue here --> #71
I also created a project to track the advancement of the Linux support --> https://github.com/Stephanevg/PSClassUtils/projects/5

from psclassutils.

I have removed linux testing support from the CI (see d2e809c) as I think that PSGraph has an issue on Linux, where we cannot do much.

This also means, that PSClassUtils currently doesn't support Linux officially.

from psclassutils.

I have removed linux testing support from the CI (see d2e809c) as I think that PSGraph has an issue on Linux, where we cannot do much.

This also means, that PSClassUtils currently doesn't support Linux officially.

from psclassutils.