Closed neilenns closed 1 year ago
Missed including one file, will add later today
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)
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 š
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.
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.
No rush/worries at all. Have a great holiday!
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.
Welcome back š Sounds like a plan, glad the PR got the wheels turning, github actions are š„°
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:
.github/workflow/release.yml
build script. It runs on Windows Server 2022 with Powershell as the shell to replicate the environment thesrc/build.ps1
script used../version
filesrc/updateversions.js
scriptsrc/build.ps1
script are now replaced with direct GitHub action steps.src/mod/build.ps1
script is reused since it was easier than trying to redo everything as GitHub actions.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