PSVersionInfo test failing due to SMA version

[rjmholt]

It looks like a PSVersionTable test is failing in CI, possibly because of a change to the version of System.Management.Automation.dll:

PowerShell/test/powershell/Host/PSVersionTable.Tests.ps1

Lines 6 to 24 in 945a232

	$sma = Get-Item (Join-Path $PSHOME "System.Management.Automation.dll")
	$formattedVersion = $sma.VersionInfo.ProductVersion
	$mainVersionPattern = "(\d+\.\d+\.\d+)(-.+)?"
	$fullVersionPattern = "^(\d+\.\d+\.\d+)(-.+)?-(\d+)-g(.+)$"
	$expectedPSVersion = ($formattedVersion -split " ")[0]
	$expectedVersionPattern = "^$mainVersionPattern$"
	if ($formattedVersion.Contains(" Commits: "))
	{
	$rawGitCommitId = $formattedVersion.Replace(" Commits: ", "-").Replace(" SHA: ", "-g")
	$expectedGitCommitIdPattern = $fullVersionPattern
	$unexpectectGitCommitIdPattern = "qwerty"
	} else {
	$rawGitCommitId = ($formattedVersion -split " SHA: ")[0]
	$expectedGitCommitIdPattern = "^$mainVersionPattern$"
	$unexpectectGitCommitIdPattern = $fullVersionPattern
	}

[iSazonov]

All works well locally.
I build with ci.psm module as our CIs do

Import-Module .\tools\ci.psm1
Invoke-CIBuild

and get

It says something was changed in last release process.

[rjmholt]

All works well locally.

Yeah I just noticed this.

So where's the 8 coming from?

[iSazonov]

So where's the 8 coming from?

From ci.psm:

function Get-ReleaseTag
{
    $metaDataPath = Join-Path -Path $PSScriptRoot -ChildPath 'metadata.json'
    $metaData = Get-Content $metaDataPath | ConvertFrom-Json
    $releaseTag = $metadata.NextReleaseTag
    if($env:BUILD_BUILID)
    {
        $releaseTag = $releaseTag.split('.')[0..2] -join '.'
        $releaseTag = $releaseTag + '.' + $env:BUILD_BUILID
    }
    return $releaseTag
}

NextReleaseTag is v7.2.0-preview.8"

[iSazonov]

if($env:BUILD_BUILID)

Oh, I wonder how this works currently and tests are passed if the env name should be BUILD_BUILDID. Came from #8822.

/cc @TravisEz13 @adityapatwardhan

[iSazonov]

It turned out that ci.psm1 always assigns it directly to dotnet and the code under if($env:BUILD_BUILID) is dead code.

[iSazonov]

@TravisEz13 @adityapatwardhan Friendly ping.

This blocks #15603

[TravisEz13]

I don't see a clear action item expressed.

[iSazonov]

@TravisEz13 I don't understand your comment.

I guess function Get-ReleaseTag is broken and must be fixed. I don't know how since it is exclusively internal MSFT process. I'd want to get a fix commit so that #15603 passes the test.

[iSazonov]

I compared builds local, CI and release and I am at a loss.

We always put Product version including GitCommitId on all files in all builds. It is right.
But we lost GitCommitId in banner and PSVersionTable in non-local builds! Did it happen by accident?

When we discussed adding a GitCommitId to the PSVersionTable, we found it important to inform users what the last commit was for this build. And we lost it. It should be in the Release build and CI builds too.
(To be clear I expect short PSVersion in banner (like PowerShell 7.2.0) and full version with GitCommitId in PSVersionTable.GitCommitId (like 7.2.0-preview.10-166-g40837dd860e1bb69dd8238ff5e5ae360a7637c13).

Perhaps this is a consequence of how the release process is going.
This definitely violates generally accepted rules of open source projects.
Our Git Tags are broken. They seem to indicate the beginning of the next milestone, but they are not due to that we are backporting commits. The only way to do it right is to have release branches in the repository.

There is a related problem here. No community can release a version similar MSFT since nobody knows which commits were backported (specially in patches) and no public release branches exist - it breaks the open source nature of the project.
MSFT can have non-public release process but MSFT must keep release branches public with right git tags.

/cc @SteveL-MSFT @TravisEz13 @adityapatwardhan for review.
.

Update: How could I build 7.2.1 with security fix for an community distribution?

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.