Skip to content

Automate Windows packaging#148

Merged
vilmibm merged 1 commit intomasterfrom
msi-action
Dec 19, 2019
Merged

Automate Windows packaging#148
vilmibm merged 1 commit intomasterfrom
msi-action

Conversation

@vilmibm
Copy link
Contributor

@vilmibm vilmibm commented Dec 11, 2019

This PR:

  • Adds config for building Windows installers
  • Adds an action for fetching exe files built by goreleaser
  • Adds an action for building Windows installers
  • Adds an action for adding MSI files to an existing GH release
  • Adds MSI signing to our release flow
  • Disables homebrew formula bumping for prereleases
  • Allows the release asset copying action to copy windows assets

Closes #155

@mislav
Copy link
Contributor

mislav commented Dec 12, 2019

@vilmibm To avoid checking in node_modules, you can build a "dist" file using ncc and check that in instead. It produces a standalone program with no depedencies other than node stdlib. The problem is that you have to regenerate that file on every commit, though. Maybe its better to switch to that approach only when you're done testing.

@vilmibm
Copy link
Contributor Author

vilmibm commented Dec 12, 2019

@mislav that was my plan. i have a lot more finicky debugging and pushing ahead of me.

@vilmibm vilmibm force-pushed the msi-action branch 3 times, most recently from 775a8b0 to 54b2465 Compare December 13, 2019 20:13
@vilmibm vilmibm force-pushed the msi-action branch 3 times, most recently from 270a813 to 10116b0 Compare December 18, 2019 22:13
@vilmibm vilmibm changed the title [WIP] MSI build, sign, release action Automate Windows packaging Dec 18, 2019
@vilmibm vilmibm marked this pull request as ready for review December 18, 2019 22:14
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Thank you for the hard work on this 🏆 🏆

Final note on housekeeping: could we move all release-related things under the script/ directory? This would be mostly to reduce clutter in the root directory.

async function go_msi(version, exePath) {
const options = {};
options.listeners = {
stdout: logData,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that if we don't specify listeners at all, the default will be to pipe stdout to process.stdout and stderr to process.stderr, which is a good default that lets us clean up logData.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yeah that's leftover from initial debugging


addToPath(wixPath);

go_msi(version, exePath);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should await, otherwise any async exception thrown in go_msi will not be subject to the catch block below

await exec.exec(
'"C:\\Program Files\\go-msi\\go-msi.exe"',
['make',
'--msi', 'gh.msi',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could the exact .msi filename be passed in as action input, or at least emitted as action output, to allow scripting that doesn't have to guess the produced filename?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

emitted as output.

['make',
'--msi', 'gh.msi',
'--out', buildPath, // default build loc fails
'--keep', // TODO needed?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is necessary anymore

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

evidently not, deleted


try {
const exePath = core.getInput('exe');
const version = github.context.ref.replace('refs/tags/', '');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also strip away the leading v? I wasn't sure whether Wix or Windows installers would handle the leading "v", so I was building installers up until now without the "v" prefix; e.g. 0.3.5.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the v seems to work fine; it builds, installs, and reports a proper version in settings.

needs: msi
runs-on: ubuntu-latest
steps:
- name: Checkout
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to run the checkout action here? I wonder if copy-release or bump-homebrew need project files being checked out at all

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we do. i put this in because it failed without it. the github context isn't populated.

project_name: gh

release:
prerelease: auto
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! 🎉

Set-StrictMode -Version Latest
$ErrorActionPreference = "Stop"

$thumbprint = "fb713a60a7fa79dfc03cb301ca05d4e8c1bdd431"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we could pass this by environment variable too, and specify it in the workflow file? Maybe it would be more visible when the cert needs to be rotated in the future

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm okay punting on it, i assume rotation won't be frequent

]
},
"shortcuts": {},
"choco": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need the "choco" section even though we're not using that part of go-msi functionality?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'd like us to be installable via choco eventually so i was going to leave it in.

This commit:

- Adds config for building Windows installers
- Adds an action for fetching exe files built by goreleaser
- Adds an action for building Windows installers
- Adds an action for adding MSI files to an existing GH release
- Adds MSI signing to our release flow
- Disables homebrew formula bumping for prereleases
- Allows the release asset copying action to copy windows assets
@vilmibm vilmibm merged commit 2675001 into master Dec 19, 2019
@vilmibm vilmibm deleted the msi-action branch December 19, 2019 21:08
mislav pushed a commit that referenced this pull request Sep 28, 2021
remove all deprecation messages and deprecated functionality
cchristous pushed a commit to cchristous/cli that referenced this pull request Feb 28, 2026
Adjust correct version variable with goreleaser
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.

Automate generating Windows .msi installer on release

2 participants