Add a Linux .deb installer CI workflow #164
Conversation
| --framework="$FRAMEWORK" \ | ||
| --runtime="$RUNTIME" \ | ||
| --self-contained=true \ | ||
| "/p:PublishSingleFile=True" \ |
There was a problem hiding this comment.
I've thought about making GCM Core a .NET Core "single-file" on all platforms recently actually.
Perhaps we should look at setting this in the shared/Git-Credential-Manager project file directly?
One issue however with the single-file model is that of signing. As I understand it, the single-file format is basically a self extracting archive, that extracts to some location and then forwards execution to this extracted location.
The binaries inside the archive (ELF on Linux, Mach-O on macOS, and PE on Windows) will not be themselves signed. Is this an issue? I know Gatekeeper on Mac can be unhappy to run executables, and also there's Apple Notarization. For Windows I know theres some groups inside of MSFT that require all signed binaries on their build machines too.
For Linux this is less an issue of course, since there's no equivalent to Authenticode or Apple Signing for ELF and the disjointed Linux world, AFAIK.
So perhaps what I'm saying is I've just talked myself out of changing this for all projects 😆
There was a problem hiding this comment.
CloudBuild is moving to requiring all binaries be signed IIRC so I would expect that to eventually be an issue if using gcm core to auth in cloud build (windows). This is an excellent question I'll see if I find the answer to.
There was a problem hiding this comment.
Very happy with the progress. Mostly a few nits and questions. The biggest improvement I could see would be a way to push the .deb as a build artifact so it is easier to consume from CI/PR builds. That could be an important step for when we do create a publishing workflow.
|
|
||
| on: | ||
| push: | ||
| branches: [ master ] |
There was a problem hiding this comment.
We will likely want these on release branch, too? cc: @mjcheetham
|
|
||
| # make the debian control file | ||
| cat >"$DEBPKG/DEBIAN/control" <<EOF | ||
| Package: gcmcore |
There was a problem hiding this comment.
Question: do we want the package to be gcmcore or gcm-core or git-credential-manager-core?
There was a problem hiding this comment.
@mjcheetham I'm guessing we should follow the precedent for the windows and mac distro naming? Which I think is git-credential-manager-core ?
There was a problem hiding this comment.
Are alias supported? I realise git-credential-manager-core is a mouthful, but it is the official name (and I'm a stickler for formalities 😛)..
| Priority: optional | ||
| Architecture: $ARCH | ||
| Depends: | ||
| Maintainer: GCM-Core <gcmcore@microsoft.com> |
There was a problem hiding this comment.
Is this a real email address?
There was a problem hiding this comment.
Not yet. But I figured we should create a legit public support email. Happy to create it and add us as owners. I noticed the email used in creating the git-vfs package uses a fake email like gitvfs@exmaple.com or something.
There was a problem hiding this comment.
gcmsupport@microsoft.com is a real email. We can use this. It forwards to the team.
There was a problem hiding this comment.
Oh and https://aka.ms/gcmcore is also a short-link that we own (it redirects to the repository page on GitHub). We also own https://github.com/GitCredentialManager, but this organisation cannot host any code repositories but only contact or readme information, per Microsoft OSS policy.
|
Both the |
This is excellent. The build I downloaded is available at this link. I found out that GitHub creds are required for this file, so my simple |
|
I downloaded it on my Windows machine and uploaded it to my Linux machine with stolee@stolee-linux-metal:/_scratch$ unzip gcmcore.zip
Archive: gcmcore.zip
inflating: gcmcore-linux_amd64.release.2.0.227.40047.deb
inflating: gcmcore-linux_amd64.release.2.0.227.40047.tar.gz
stolee@stolee-linux-metal:/_scratch$ sudo dpkg -i gcmcore-linux_amd64.release.2.0.227.40047.deb
Selecting previously unselected package gcmcore.
(Reading database ... 207831 files and directories currently installed.)
Preparing to unpack gcmcore-linux_amd64.release.2.0.227.40047.deb ...
Unpacking gcmcore (2.0.227.40047) ...
Setting up gcmcore (2.0.227.40047) ...
stolee@stolee-linux-metal:/_scratch$ git-credential-manager-core version
Git Credential Manager version 2.0.216-beta+4c43d7b1a6 (Linux, .NET Core 3.1.7) |
There was a problem hiding this comment.
LGTM! Thanks @kyle-rader
One question for everyone.. do we want to/can we have the Debian package run git-credential-manager-core configure after install or not? And if so, with or without --system?
For those not familiar with the configure command.. this will set the following configuration in either the user's (--global in Git parlance) ~/.gitconfig, or the /etc/gitconfig (--system) file:
[credential]
helper =
helper = manager-core
[credential "https://dev.azure.com"]
useHttpPath = true|
|
||
| on: | ||
| push: | ||
| branches: [ master ] |
Build a
.debpackageOverview
Adding another GHA workflow to build installers. Happy to rename this to specifically build the Linux installer. The other CI I made uses a matrix run to the base build and test on all platforms.
If there are platform specific tasks, like platform specific tests and building an installer we could make a platform specific workflow for each of those.
One
build.shThis PR is a adding a build step but is a net reduction in bash from merging into one
build.shfor the Payload.Linux project. I found it very confusing to have the build not happen inbuild.sh. The duplicated arg parsing in the 3 bash scripts seems like an un-needed 3x amount of potential parsing bugs plus each script was redefining several varsbuild.shalready defined.Future work
I'm figuring out internally how to onboard this project to the ESRP signing process so we can publish to packages.microsoft.com. I expect I'll have to make more edits for that process specifically to either download the signing client and run it or send the bits off to be signed. I don't yet know if we can do this in GHA.