Release Build Workflow Action

[IAmVigneswaran]

@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.

[orchetect]

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.

[IAmVigneswaran]

To simply the release build steps -

• Maybe we edit and update the CHANGELOG.md manually?

• Not sure if this could be possible. We can have a version.txt file. Something similar to this. We can edit and increase the version number if we want to officially push a build to the release page. Else, we can just grab the build binaries from the Action tab for internal testing.

[orchetect]

edit and update the CHANGELOG.md manually

We already do, and that won't change.

We can have a version.txt file.

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.

[IAmVigneswaran]

@orchetect I tried to create a release_github.yml using ChatGPT. 😅

It would extract version number from the Version.swift file. Not sure if it would work.

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

[IAmVigneswaran]

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 .pkg file and as well archives it as .zip.

It will automatically extracts version number from the Version.swift.

[orchetect]

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, /Applications is not where command line utilities typically get installed. The recommended location is /usr/local/bin/. (https://apple.stackexchange.com/a/98626/51641)

To that point, we should get Homebrew set up so users can just install using a brew command.

[IAmVigneswaran]

There's a CLI zip & pkg in the release, but we don't need both. Should really only be one or the other.

1. I have deliberately intended two releases. Personally, I prefer .zip archive. Since, I have macOS Gatekeeper disabled on my Mac, it is much easier for me to download the .zip archive and replace the binary within my existing folder and setup. And it is also for users who have a similar setup and who prefers a "portable" release.

2. If someone wants to develop a custom app or tool that needs our MarkersExtractor binary in their workflow, they easily download our .zip archive.

3. Yes, I have thought and contemplated on using /usr/local/bin location for our binary. It might not be an issue. But it is an issue for me at least. 😅 Personally, I don't like apps or tools that installs files in hidden location. The /usr/local/bin is hidden to the user. If the user wants to uninstall or delete the binary for some reason, they need to to show all files in Finder to access /usr/local/bin. Which might not be recommended for normal users, since it exposes OS level files.

To show hidden files and folders, enter this command into Terminal:
defaults write com.apple.finder AppleShowAllFiles TRUE ; killall Finder

To hide those files again, enter this command into Terminal:
defaults write com.apple.finder AppleShowAllFiles FALSE ; killall Finder

I just want to provide users with transparency, access and options. The .pkg is for folks who are uncomfortable in disabling macOS Gatekeeper. They would know where the tool is installed. They can easily delete the folder from their /Applications without invoking any special terminal commands.

This was my rational.

To that point, we should get Homebrew set up so users can just install using a brew command.

That would be great! I have no clue. But I can do some reading and research on this.

[orchetect]

1. [...] a "portable" release.
2. [...]

Fair, that's fine.

3. I don't like apps or tools that installs files in hidden location.

Except the point of /usr/local/bin is that the contents are usable from any directory, because it's in the shell environment's PATH. It's a convention that's been in use for decades. Then you don't have to manage a path to the CLI when using it, you can just invoke directly.

Plus, it's just bad form to place CLI executables in /Applications. At that point, you may as well not have a pkg installer at all and just provide the zip file.

[latenitefilms]

That would be great! I have no clue. But I can do some reading and research on this.

See: CommandPost/CommandPost#3291

[IAmVigneswaran]

@orchetect Done! I have updated the install path to /usr/local/bin. And I have added portable text to the .zip release.

https://github.com/TheAcharya/MarkersExtractor/releases/tag/0.3.3

@latenitefilms Thanks for info. I will do more reading about distributing tools to brew.

[orchetect]

I have updated the install path to /usr/local/bin

Just tested the pkg installer and works as expected. Nice!

distributing tools to brew

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.

[orchetect]

Just ran the release workflow for 0.3.4. It looks like there's codesign issues, as I'm getting this when running the portable CLI:

Would be good to get that fixed for 0.3.5.

[IAmVigneswaran]

Let me try and fix this soon.

[IAmVigneswaran]

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.
You can only staple the Notarisation ticket on a .pkg or a .dmg file. It was the reason why I included the .pkg for download.

https://forums.developer.apple.com/forums/thread/114961

https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow#3178137

If you were to check the code signature using codesign, it should show that the signatures are correctly signed.

The portable file is more for our internal test. You can right-click and press open.

[orchetect]

Yeah, that sounds right. Been a while since I dug into that.

[orchetect]

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.

[IAmVigneswaran]

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]

"portable" seems redundant and fairly obvious, no?

I think it would be a bit cleaner if we just did pkg and zip with the same base filename.

markers-extractor-cli-0.3.5.pkg


markers-extractor-cli-0.3.5.zip