GCM Release 2.0.886 #994
Merged
GCM Release 2.0.886 #994
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If there is no hard-coded UI helper, we should gracefully handle the lookup by returning false, rather than crashing due to a argument exception when passing `null` or an empty string to a Path API.
Ensure that we don't return empty `PATH` values on Windows when splitting. It's common that on Windows the `PATH` can be inadvertently modified such that an empty value is included, and this can lead to weird resolution of executables using the current directory. As it stands, no existing codepaths would trigger this today when invoked by Git for Windows, but let's make sure this never happens in the future by mistake!
On Windows, when invoked as a partial name (e.g., `manager`) our command line argv[0] is just a file name, not a full file path! We incorrectly assumed that `Environment.GetCommandLineArgs()[0]` was always absolute! We should instead use `AppContext.BaseDirectory` that, in all circumstances tested, all on TFMs and OSs, all publish options, and as a .NET tool... returns the expected full, absolute path to the installation directory.
Fix a bug in the old-name warning detection that only presents on Windows when bundled with Git for Windows, and when configured using the shorthand config `credential.helper=manager-core`. In this scenario, our argv[0] is missing the ".exe" extension (that's actually present in the file name of course) because ... mingw reasons. Instead of matching "git-credential-manager-core.exe" on Windows, just strip ".exe" if present on Windows, and always match "git-credential-manager-core" on all platforms.
Fix another bug in how we compute the Application Executable path on Windows. It some cases we can still get a relative/non-absolute path to the entry executable. If we get a filename/non-path from the native API calls then return null and fallback to using process/module image resolution instead. For .NET Framework on Windows, this is OK. We will want to revisit this on .NET (Core) on Windows, if and when we get around to that...
Update Debian package uninstall instructions to reflect re-name of GCM Core to GCM.
Bumps [DavidAnson/markdownlint-cli2-action](https://github.com/DavidAnson/markdownlint-cli2-action) from 7.0.0 to 8.0.0. - [Release notes](https://github.com/DavidAnson/markdownlint-cli2-action/releases) - [Commits](DavidAnson/markdownlint-cli2-action@e3969ef...d57f8bd) --- updated-dependencies: - dependency-name: DavidAnson/markdownlint-cli2-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
….0.0 (#976) Bumps [DavidAnson/markdownlint-cli2-action](https://github.com/DavidAnson/markdownlint-cli2-action) from 7.0.0 to 8.0.0.
Update Debian package uninstall instructions to reflect re-name of GCM Core to GCM. Fixes #973
Split the current build.sh script into 3 scripts: build.sh, layout.sh, and pack.sh. This has the advantages of decoupling building and packaging and more-closely reflects the process we use for building/packaging macOS binaries.
Sign Linux tarball in addition to Debian package.
Split pack-tool.sh into two scripts (layout.sh and pack.sh) to allow for payload and package signing.
Update release workflow to sign the .NET tool payload and package and upload the nupkg with each release (in addition to publishing to nuget.org).
Update release workflow to: 1. Split the Linux `build.sh` script and the .NET tool `pack-tool.sh` script to more closely align with our compilation and packaging for macOS. 2. Sign Linux tarball in addition to the Debian package.and sign/validate/publish .NET tool `.nupkg`. 3. Sign/validate/publish the .NET tool `.nupkg` with every release. I validated these changes with [this successful workflow run](https://github.com/ldennington/git-credential-manager/actions/runs/3651681219) in my fork.
The changes from 3978b0e introduced a bug in the install from source workflow - we were attempting to copy binaries before publishing them! Fixing with this change.
The changes from 3978b0e introduced a bug in the install from source workflow - we were attempting to copy binaries before publishing them! Fixing with this change. Validated with [this passing workflow](https://github.com/ldennington/git-credential-manager/actions/runs/3652773502) in my fork.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes: