-
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
heimdal: update to 7.8.0 #63
Conversation
The URL currently works, but has a version hardcoded in it that should not be hardcoded. Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Git for Windows automation <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Let's see what will happen when I deploy the x86_64 build... |
As I thought. It's now marked as "Inactive". I guess the standard model of deployments via workflows is that you first build all your artifacts, then deploy them all in another workflow run. The problem with that model is that the mere act of using an environment is already considered as constituting a deployment, and environments are the only way to guard secrets behind manual gates, which is something I want to do with that package signing. And it does not seem as if you can sign Pacman packages after building them, only while building them (the This poses a problem: The only deployment model available to us appears to be incompatible with Pacman's package building/signing process. |
Hmm. It looks like I was wrong on that one. Judging by this code and this code, all
So I guess that this part of |
Having said that, the code-signing of the executables inside the Pacman packages is still something that needs to be done during the build. I am currently not sure how to deal with that issue. |
The deployments worked, and I will have to think more about approaches how to move them completely to GitHub workflows. But I can do that elsewhere, no need to "hold this PR hostage", i.e. I will merge it. |
This closes git-for-windows/git#4118