-
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release Build Workflow Action #52
Comments
Noted. There are a number of manual steps involved currently that may be difficult to automate and provide sufficient failsafe checks, but yes, it may be possible to automate a large portion of the process. |
To simply the release build steps -
|
We already do, and that won't change.
I do something similar in other repos, but for the time being I have moved the CLI's version string to its own swift file which will make it simpler to update through automated scripts. |
@orchetect I tried to create a release_github.yml using ChatGPT. 😅 It would extract version number from the name: release_github
on:
workflow_dispatch:
inputs:
release:
description: 'Release after build'
required: true
default: 'no'
push:
branches:
- main
env:
SWIFT_VERSION: '5.5' # Define your desired Swift version here
PACKAGE_NAME: markers-extractor-cli
WORKSPACE_PATH: 'MyProject.xcodeproj' # Define the path to your Xcode project or workspace here
jobs:
build:
runs-on: macos-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Extract version number
id: extract_version
run: |
CLI_VERSION=$(sed -n 's/.*let cliVersion = "\(.*\)".*/\1/p' Version.swift)
echo "CLI_VERSION=$CLI_VERSION" >> $GITHUB_ENV
shell: bash
- name: Set up Swift
uses: actions/setup-swift@latest
with:
swift-version: ${{ env.SWIFT_VERSION }}
- name: Build Swift project
run: |
swift build --configuration release -Xswiftc "-DVERSION=\(CLI_VERSION)" -Xswiftc "-workspace" -Xswiftc "${{ env.WORKSPACE_PATH }}"
working-directory: ${{ env.PACKAGE_NAME }}
- name: Create release archive
run: |
mkdir dist
cp .build/release/${{ env.PACKAGE_NAME }} dist/
cd dist
zip -r ${{ env.PACKAGE_NAME }}-${{ env.CLI_VERSION }}.zip ${{ env.PACKAGE_NAME }}
working-directory: ${{ env.PACKAGE_NAME }}
- name: Save release artifact
uses: actions/upload-artifact@v2
with:
name: release_dist
path: dist |
I have added a new release_github action. We can use this action to create any future releases. It builds the CLI, code-sign, notarise and staples the binary as It will automatically extracts version number from the |
Good stuff. There's a CLI zip & pkg in the release, but we don't need both. Should really only be one or the other. Also, To that point, we should get Homebrew set up so users can just install using a |
I just want to provide users with transparency, access and options. The This was my rational.
That would be great! I have no clue. But I can do some reading and research on this. |
Fair, that's fine.
Except the point of Plus, it's just bad form to place CLI executables in |
|
@orchetect Done! I have updated the install path to https://github.com/TheAcharya/MarkersExtractor/releases/tag/0.3.3 @latenitefilms Thanks for info. I will do more reading about distributing tools to |
Just tested the pkg installer and works as expected. Nice!
This is how most end-users of the CLI will likely install MarkersExtractor because it's convenient, so it would be good to add to our release pipeline, either manually or automated. |
Let me try and fix this soon. |
After investigating, I realise that the current workflow action is setup correctly. You would not be able to staple the notarisation ticket on a CLI binary. It is not possible. https://forums.developer.apple.com/forums/thread/114961 ![]() If you were to check the code signature using The portable file is more for our internal test. You can right-click and press ![]() |
Yeah, that sounds right. Been a while since I dug into that. |
On a separate note, the portable executable is being zipped with an enclosing folder which isn't necessary. We should modify the release script to just zip the executable itself without a folder. |
Actually, during the setup of the Workflow Action, I attempted to directly zip the CLI binary. However, I encountered an issue where the codesigned binary executable would become corrupted upon downloading and extracting, if it was zipped directly by GitHub. This problem also occurred with Marker Data.app. As a workaround solution, I enclosed the executable within a folder to prevent corruption. I have reported this issue to GitHub. |
@orchetect Right now we have a build.yml to check and test the code.
I am wondering if we can create a release build workflow as well? Something similar to this.
That way we easily build the binaries and release them via actions.
The text was updated successfully, but these errors were encountered: