Skip to content
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 66 commits into from
Nov 1, 2023
Merged

Create release for GCM 2.4.0 #1457

merged 66 commits into from
Nov 1, 2023

Conversation

mjcheetham
Copy link
Collaborator

Changes:

mjcheetham and others added 30 commits August 15, 2023 15:17
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>
ldennington and others added 22 commits October 12, 2023 17:16
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!
@mjcheetham mjcheetham self-assigned this Nov 1, 2023
@mjcheetham mjcheetham merged commit d575193 into release Nov 1, 2023
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.