dementedmonkey / cj4-mcdu

MCDU Web application for the Working Title CJ4
GNU General Public License v3.0
32 stars 4 forks source link

Add release building via GitHub workflow #35

Closed neilenns closed 1 year ago

neilenns commented 1 year ago

This PR adds automatic release builds via GitHub actions, so you don't have to remember the steps in buildnotes.md every time you want to cut a release.

With these changes building a release is as simple as creating a new release in GitHub. Set the version number as the tag (e.g. v0.5.0), publish the release, then wait. The action will take about two minutes to complete and then attaches the release zip file to the release in GitHub automatically.

You can also manually trigger a release build via the Actions tab. This is helpful if you want a one-off package for testing without publishing a full release to the public.

Changes:

Note that this depends on src/app/package-lock.json being checked in to the GitHub repo (issue #32).

Here's an example of the output of this workflow: https://github.com/neilenns/cj4-mcdu/releases/tag/v0.5.0 Here's the log of the build output: https://github.com/neilenns/cj4-mcdu/actions/runs/3749736042/jobs/6368549784

neilenns commented 1 year ago

Missed including one file, will add later today

dementedmonkey commented 1 year ago

Looks reasonable, but I'm going to have to go off and learn about Github actions before I pull it.

(At work, our github server doesn't have actions enabled, so it's all Jenkins. I get what's going on, just want to understand the mechanics)

neilenns commented 1 year ago

Looks reasonable, but I'm going to have to go off and learn about Github actions before I pull it.

Here's a decent overview of them: https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions. A good example of where I've used them in the past is here: https://github.com/MobiFlight/MobiFlight-FirmwareSource/tree/main/.github/workflows. There's a release workflow that's similar to what this PR does (you'll recognize some of the steps). There's also a CI workflow that auto-attaches the binaries to every pull request, which is handy for testing purposes.

(At work, our github server doesn't have actions enabled, so it's all Jenkins. I get what's going on, just want to understand the mechanics)

Ah Jenkins. I have (fond?) memories šŸ˜

neilenns commented 1 year ago

Seems to work calling build.ps1 directly. I modified it to use npm ci and include exit 0 at the end.

Example output from the run: https://github.com/neilenns/cj4-mcdu/suites/9999214021/artifacts/485439720. Ignore the fact that it's a zip inside a zip, that's just an oddity of attaching artifacts to the workflow run itself instead of the release.

If you wanted to maintain npm install when run locally we should be able to test for whether the GITHUB_WORKFLOW environment variable is set to know if it is running in a workflow context.

dementedmonkey commented 1 year ago

The npm ci is fine, since this is really "run the production build locally."

I'll be running around a bit for the holidays, may take a week or two until I get a chance to pull this.

neilenns commented 1 year ago

No rush/worries at all. Have a great holiday!

dementedmonkey commented 1 year ago

There are a few changes I'd like to make, so I'll pull this onto a temporary branch, then merge that to master.

This workflow requires publishing a release, after which the build comes in and edits it to add the files. I'm going to change the triggering so that it creates the release based on the creation/update of the version label.

The version extraction steps are warning about deprecation because of some github security theater and they use node 12. Pulling out the without-a-v version is some trivial powershell so I'll do that.

I'll also try to do something sensible with the version number in the files.

neilenns commented 1 year ago

Welcome back šŸ˜† Sounds like a plan, glad the PR got the wheels turning, github actions are šŸ„°