-
Notifications
You must be signed in to change notification settings - Fork 32
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
mintty: update to 3.6.2 #62
Conversation
Signed-off-by: Johannes Schindelin <[email protected]>
Hmm... This PR is part of some investigation how to change Git for Windows' deployment processes, away from an opaque Azure Pipeline toward a more transparent, branch-deploying one. But... It would appear that the "temporary (inactive) deployment" was the i686 one, and the x86_64 one was marked as "active". I guess we have to make this a matrix build that defaults to building for both architectures and then a dependent job deploying all the artifacts that have been built at the same time, much as the Azure Pipeline does that I am seeking to replace with a more transparent, fully GitHub-based solution. |
Over at dscho#8 is the result of an experiment investigating whether we can use a "simple" workflow to automate opening these PRs, without needing to provide a separate token. Here is the workflow run: https://github.com/dscho/MSYS2-packages/actions/runs/3475076556 Sadly, the experiment kind of failed: since the PR is opened using the workflow's token, it cannot trigger other runs, including the CI builds. But we do want those builds to happen, to build confidence that the package can be built (and sometimes even testing the produced artifact) before starting the deploy. I will have to think about ways how to adjust this workflow so that we can automate all of this. One idea I have is to build a static web page (via Naturally, that static web page would need to pass a Personal Access Token to the workflow so that it can be used to open the PR. The trick will be to do all of this securely. An idea to make it super extra secure (which is probably overkill) is to do this:
Now that I've written all this up, it strikes me as a really complex and complicated solution to the problem. Hopefully I (or others) can think of better solutions. A simpler alternative would avoid the GitHub App altogether and ask for a PAT (that the users have to generate themselves), pass that as a regular on:
workflow_dispatch:
inputs:
pat:
description: The Personal Access Token
type: string
required: true
jobs:
open-pr:
steps:
- name: mask token
# Do not use ${{ github.event.inputs.pat }} directly because that would log
# the token verbatim to the log as part of the code snippet since it has not
# been masked before running the snippet.
run: echo "::add-mask::$(jq -r '.inputs.pat' <$GITHUB_EVENT_PATH)" This would be simpler, at the expense of security (the token gets passed unencrypted via A variation on this would be a GitHub App (backed by a relative simple Azure Function, based on this toy GitHub App) which would generate the OAuth token, encrypt it using its public key and store that in a cookie (so that it can run serverless, i.e. all the state is stored in the cookie). The Azure Function would serve an "almost static" page, trigger the |
Let's merge this, and continue developing this new process over in this ticket, which I plan on addressing using the same workflow as I used for the |
This PR supersedes #61, using a branch in the git-for-windows/MSYS2-packages repository so that it can be branch-deployed from here.
See https://github.com/mintty/mintty/releases/tag/3.6.2 for details.
This closes git-for-windows/git#4114