Windows 32/64 Github Action Builds #166
Conversation
.github/workflows/build-windows.yml
Outdated
| key: bazel | ||
|
|
||
| - name: Install protoc | ||
| uses: arduino/setup-protoc@v1 |
There was a problem hiding this comment.
I don't think we can use this for security reasons. Can you do something like this instead?
There was a problem hiding this comment.
Sure. That will probably make it so I can completely skip the custom action but I'll see.
There was a problem hiding this comment.
I've now completely removed the arduino/setup-protoc dep and standardized the download of the protoc executable/includes between build.yml and codeql.yml
Should you want to update the version, you can now just copy and paste the top environment variable between the two files easily.
This also simplified the actual codeql.yml config as well into separate steps.
|
Overall this looks fantastic. Thank you for putting it together! |
| - name: Install Protoc | ||
| run: | | ||
| echo "Fetching protoc" | ||
| curl --header 'Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \ |
There was a problem hiding this comment.
This ensures we don't get rate capped for any reason (not that we would :))
| -L https://github.com/protocolbuffers/protobuf/releases/download/v${PROTOC_VERSION}/protoc-${PROTOC_VERSION}-${PROTOC_PLATFORM}.zip \ | ||
| --output protoc-release.zip | ||
| unzip protoc-release.zip -d protoc-release | ||
| rm protoc-release.zip |
There was a problem hiding this comment.
There was no need for that whole $GITHUB_WORKSPACE stuff since it's all being executed in that directory as it is.
| name: js | ||
| path: | | ||
| google-protobuf.js | ||
There was a problem hiding this comment.
These generated files should be the same no matter what platform we package the "protoc-gen-js/.exe" for so we can use the same assets
| unzip $GITHUB_WORKSPACE/protoc-release.zip -d $GITHUB_WORKSPACE/protoc-release | ||
| echo "Clean, install, and test protobuf-javascript" | ||
| npm ci | ||
| npm install |
There was a problem hiding this comment.
npm ci and npm install are the same except that npm install can modify the package-lock.json. npm ci does not so you should just use that.
| ) | ||
|
|
||
| config_setting( | ||
| name = "k8", |
There was a problem hiding this comment.
Technically not required for the windows build but it doesn't hurt anything so I left it here so you can strill build the linux-x86_64 build using --cpu k8
|
Any chance we could get the existing win32 and win64 zip files in the 3.21.2 release updated with the versions built by the |
|
Yes, planning to, just ran out of time the other day. I'll ping the bug thread when it's done. |
Fixes #142
This PR includes minor changes to the Bazel build process and new GitHub Actions/Workflows to facilitate building the Windows 32/64 release zip files using the Visual Studio toolset ensuring it's compatibility on all Windows systems (not just in minGW). The Bazel changes should be compatible with existing internal build processes and should not affect the non-Windows releases controlled by Google's internal build system. They are only so we can pass the "--cpu" argument in Github Actions and properly name the output release file.
See the release created by the tag submitted with this PR at:
https://github.com/yinzara/protobuf-javascript/releases/v3.21.2
I was actually successful in building the Mac OS x86/ARM and Linux x86_64 releases as well.
https://github.com/yinzara/protobuf-javascript/releases/tag/v3.21.2-yinzara-2
Unfortunately building the other architectures would either require a new toolchain or potentially using https://github.com/uraimo/run-on-arch-action. However, either was beyond the scope I was tackling and both wouldn't be able to produce the x86_32 architecture.
I've disabled the Mac OS and Linux builds in the github action workflow file for now (with comment explaining why).
If a release was already created via an internal tool before the tag is pushed to Github, this should properly add to the existing release (instead of creating a new one) because of the
svenstaro/upload-release-action@v2behavior.I tested this by rerunning the release step of the build and it only updated the executables without creating a new release.
Initial release:
https://github.com/yinzara/protobuf-javascript/actions/runs/4379577450/attempts/1
Rebuild:
https://github.com/yinzara/protobuf-javascript/actions/runs/4379577450
I suggest after this PR is merged that someone take the auto build win32/win64.zip files and update the existing 3.21.2 release so that people downloading the new files will have the fixed version that works in Powershell and Windows apps.