-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create release for GCM 2.4.0 #1457
Merged
Merged
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
Rename the lone GetToken method to clarify that this is for user principals (regular user identities). This is in preparation for adding extra principal types including service principals, and managed identities. Also add some XML doc comments to the method.
Refactor the token cache helper methods to allow us to re-use the existing cache registration logic with a different ITokenCache and StorageCreationProperties. This will be useful when we later introduce a confidential client application (for service principals) that needs a different cache location, and uses the AppTokenCache, rather than the User one.
Add support for acquiring a token for a service principal. Either a client secret or certificate can be used to authenticate (the latter being preferred).
Add support for obtaining an access token using either the system-assigned and a user-assigned managed identity.
Add app token cache support for confidential client applications (service principals). This is a different cache than the one for user tokens that is used by public client applications (for normal users). We do not know of any other app token cache that we can share with currently, so we just use our own in the GCM data directory.
Allow a service principal or managed identity to be used to authenticate against Azure Repos. Required information for service principals is specified in Git config or environment variables, as is the ID for a managed identity.
Add tests of the `GetCredentialAsync` method on the `AzureReposHostProvider` using managed identity and service principal.
Use the correct name for setting the target of a tag in the release workflow, for creating a draft release.
Use the correct name for setting the target of a tag in the release workflow, for creating a draft release. It should be `target_commitish` not `tag_commitish`. https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release Thanks to @dscho for realising my error.
Add support for both managed identities and service principals for Azure Repos authentication. Service principals are the "service account" equivalent to normal "users" (user principals). Rather than a password+MFA, service principals (SP) authenticate either with a 'secret' or a certificate - we support both. Managed identities (MI) are an evolution of service principals whereby the secret/certificate are hidden and managed by Azure. There are two types of managed identities: system-assigned and user-assigned. System-assigned are tied to a particular VM or resource, whereas user-assigned can be shared between VMs/resources. Azure DevOps recently learned to support SPs and MIs as identities that can be members of orgs and projects. Note that this only applies to AAD-connected Azure DevOps orgs. This functionality is most compelling for automated scenarios, like CI machines, that need access to Azure Repos. Fixes #1313
Update `release-homebrew` workflow to use the `brew bump-cask-pr` command [1]. This aligns with the Homebrew project's official recommendations for creating PRs in the `Homebrew/homebrew-cask` tap and removes GCM's dependency on the `mjcheetham/update-homebrew` task [2]. 1: https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request#submit-a-new-version-of-an-existing-cask 2: https://github.com/mjcheetham/update-homebrew
Update `release-homebrew` workflow to use the `brew bump-cask-pr` command [1]. This aligns with the Homebrew project's official recommendations for creating PRs in the `Homebrew/homebrew-cask` tap and removes GCM's dependency on the `mjcheetham/update-homebrew` task [2]. 1: https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request#submit-a-new-version-of-an-existing-cask 2: https://github.com/mjcheetham/update-homebrew
Update from Avalonia 11.0.0-preview6 to 11.0.4 and fix the codes using APIs removed since 11.0.0 release.
We have not been consistently detecting or normalising "gist" URLs for dotcom or GHES instances. Gists are backed by a Git repository and can be cloned/pushed-to etc like a normal repository. Credentials are the same as the base site. Update our OAuth, rest API, and dotcom-detection methods that deal with the remote or target URL to correctly support gists URLs. Also add some tests around this.
We have not been consistently detecting or normalising "gist" URLs for dotcom or GHES instances. Gists are backed by a Git repository and can be cloned/pushed-to etc like a normal repository. Credentials are the same as the base site. Update our OAuth, rest API, and dotcom-detection methods that deal with the remote or target URL to correctly support gists URLs. Also add some tests around this. Fixes #1401
Update custom install to define a default path in `Packaging.Linux.csproj`. Include a few spelling/grammar/refactoring tweaks as well.
Update the URL for the Azure DevOps product page. This used to be just https://dev.azure.com, but this now redirects you to https://azure.microsoft.com/en-us/products/devops instead. The markdown link linter times out following the redirect, so let's just update the original link.
install from source: custom install location edits
Update the URL for the Azure DevOps product page. This used to be just https://dev.azure.com, but this now redirects you to https://azure.microsoft.com/en-us/products/devops instead. The markdown link linter times out following the redirect, so let's just update the original link.
Bumps [DavidAnson/markdownlint-cli2-action](https://github.com/davidanson/markdownlint-cli2-action) from 11.0.0 to 12.0.0. - [Release notes](https://github.com/davidanson/markdownlint-cli2-action/releases) - [Commits](DavidAnson/markdownlint-cli2-action@8f35160...3aaa38e) --- 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>
Update macOS component of release workflow to use GitHub certificates for signing and notarization.
Update Windows component of release workflow to use Azure Code Signing.
Update the .NET tool release workflow to use the workflow's Federated credential for Azure access. Additionally, update ESRP setup to use secrets instead of storage account/resource names.
Upload GCM's public key as a release asset. Add instructions for users to import this key and use it to validate the latest Debian package and tarball.
This PR fix #1304. I found that the add func add_to_PATH [1] doesn't persist the path to the $PATH env variable. To persist in the current shell is necessary to use a dot or `source` see doc [2]. _When a script is run using source it runs within the existing shell, any variables created or modified by the script will remain available after the script completes. In contrast if the script is run just as filename, then a separate subshell (with a completely separate set of variables) would be spawned to run the script._ To persist the PATH among the reboot/new shell, it is necessary to update the _.profile_ with `echo 'PATH="$PATH:$installPath' >>~/.profile`. I don't know if this is the correct behavior, Prior to this commit, it was working because the `/usr/local/bin` is already in the PATH. [1]: https://github.com/git-ecosystem/git-credential-manager/blob/afcb6b87302b34d1809a0a057f24c7ba7a3ff5db/src/linux/Packaging.Linux/install-from-source.sh#L94 [2]: https://ss64.com/bash/source.htmlvvvvvvv
Introduce a flag to switch Avalonia to use software rendering rather than hardware/GPU-based. There is an open Avalonia issue[1] on Windows when run on certain ARM64 GPUs. Until this is solved, introduce this workaround flag. [1]: AvaloniaUI/Avalonia#10405
This PR migrates GCM's Linux, macOS, and Windows signing workflows off the ESRP service. This means: 1. Updating the Linux components to sign with a GPG key. 2. Updating macOS components to sign/notarize using Application and Installer certificates (see this series [1] for details). 3. Updating Windows components to sign using the Azure Code Signing service. **Note:** This PR does not include updates to migrate the .NET tool package signing off ESRP for two reasons: 1. The Azure Code Signing service does not yet support NuGet package signing. We are hopeful this will be our solution in the future, though. 2. HSM requirements for Code Signing certificate storage [2]. An example run of release workflow with these changes can be found here [3]. 1: https://developer.apple.com/forums/thread/701514 2: https://knowledge.digicert.com/generalinformation/new-private-key-storage-requirement-for-standard-code-signing-certificates-november-2022.html 3: https://github.com/ldennington/git-credential-manager/actions/runs/6543297870
Co-authored-by: Matthew John Cheetham <mjcheetham@github.com>
Default to software GUI rendering on Windows on ARM. Users can explicitly set the config to re-enable HW accelerated rendering if they wish.
Since we're targetting .NET Framework 4.7.2 there are some unnecessary conditional compliation `#if NETFRAMEWORK` blocks. Namely around CLR and runtime/OS detection.
Add ability to disable hardware acceleration when drawing Avalonia-based GUI prompts on Windows. This is a useful workaround for an issue on certain ARM64 devices where the windows appear empty. AvaloniaUI/Avalonia#10405 https://developercommunity.visualstudio.com/t/Git-authentication-dialog-is-invisible-o/10467795
Since we're targetting .NET Framework 4.7.2 there are some unnecessary conditional compliation `#if NETFRAMEWORK` blocks. Namely around CLR and runtime/OS detection.
In removing the Avalonia setup workaround in #1445 we forget to replace the SetupWithLifetime call with just SetupWithoutStarting!
In removing the Avalonia setup workaround in #1445 we forget to replace the SetupWithLifetime call with just SetupWithoutStarting!
vdye
approved these changes
Nov 1, 2023
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: