Objo Publisher GitHub Actions

madamov

I have published two public GitHub repositories that make it easy to build and publish Objo Studio applications using GitHub Actions.

Repositories

ObjoPublisher

https://github.com/madamov/ObjoPublisher

This repository contains reusable GitHub Actions workflows for publishing Objo applications on all supported platforms.

The workflows automatically:

download or restore the requested Objo Studio version from cache,
activate and deactivate an Objo Studio license,
publish applications,
optionally sign and notarize macOS applications,
optionally sign Windows MSIX packages,
collect build artifacts,
upload build artifacts,
cache Objo Studio installations for future workflow runs.

Available reusable workflows:

publish_objo_macos.yml
publish_objo_linux.yml
publish_objo_windows.yml
publish_objo_windows_objosign.yml

ObjoBuilder

https://github.com/madamov/ObjoBuilder

This repository demonstrates how the reusable workflows can be consumed from application repositories.

It contains example workflows for all supported publishing scenarios:

Workflow	Demonstrates
objopublisher_publish_macos.yml	Calling the reusable macOS publishing workflow, publishing one or more macOS targets, uploading the generated DMG files, and downloading the published artifacts in a subsequent job.
objopublisher_publish_linux.yml	Calling the reusable Linux publishing workflow, publishing one or more Linux targets, uploading the generated archives, and downloading the published artifacts in a subsequent job.
objopublisher_publish_windows.yml	Calling the reusable Windows publishing workflow that signs MSIX packages using the official Azure Trusted Signing GitHub Action, then downloading the signed artifacts in a subsequent job.
objopublisher_publish_windows_objosign.yml	Calling the reusable Windows publishing workflow that lets Objo Studio perform Azure Trusted Signing during publishing, then downloading the signed artifacts in a subsequent job.
check_syntax.yml	Restoring a cached Objo Studio installation, activating an Objo Studio license, automatically locating the `.objosln` file, running `objo check`, and deactivating the license.
cache_objo_studio.yml	Downloading and caching the latest released version of Objo Studio for macOS, Linux, and Windows runners.

Every publishing example consists of two jobs:

A job that calls one of the reusable workflows in ObjoPublisher.
A second job that demonstrates how to download the artifacts produced by the reusable workflow using actions/download-artifact.

This makes the repository a practical reference not only for publishing applications but also for consuming the generated artifacts in later workflow jobs.

Why reusable workflows?

Most projects require exactly the same publishing pipeline:

install Objo Studio,
activate a license,
publish the application,
optionally sign it,
collect artifacts,
upload artifacts,
deactivate the license.

Without reusable workflows, every repository ends up maintaining nearly identical YAML files. Any improvement or bug fix must then be copied into every project.

By moving the publishing logic into ObjoPublisher, application repositories become much simpler—they only provide project-specific inputs and secrets, while all publishing logic is maintained in one place.

Benefits include:

centralized maintenance,
consistent publishing behavior across projects,
smaller workflow files,
automatic Objo Studio caching,
easier updates and bug fixes,
less duplicated YAML.

Windows publishing workflows

There are two different Windows publishing workflows because Objo Studio supports two different approaches to Azure Trusted Signing.

Workflow	How signing is performed	Recommended when
publish_objo_windows.yml	Objo publishes the MSIX package. The workflow then signs it using the official `azure/trusted-signing-action`.	You want to use Microsoft's supported GitHub Action and keep signing separate from publishing.
publish_objo_windows_objosign.yml	Objo publishes and signs the MSIX itself by invoking Microsoft's Azure Artifact Signing Client Tools.	You prefer Objo Studio to perform the complete publish-and-sign process.

Both workflows produce signed MSIX packages but use different signing mechanisms.

Current status of the Objo signing workflow

The publish_objo_windows_objosign.yml workflow has not yet been fully tested.

Although the workflow itself is complete, my Azure Trusted Signing account currently does not have sufficient permissions to perform end-to-end testing of the signing process through Objo Studio.

The reusable workflow has been implemented based on the documented behavior of Objo Studio and the Azure Artifact Signing Client Tools, but additional validation by users with full Azure Trusted Signing permissions would be greatly appreciated.

Garry

Wow. This is wonderful @madamov. Thank you for putting so much work into it!

This is exactly the sort of workflow I hoped the VCS-friendly .objosln format and objo CLI would enable. Seeing genuine macOS, Linux, and Windows GitHub Actions runs is especially satisfying. Splitting the reusable publishing logic into ObjoPublisher and keeping application workflows small is a very sensible design.

I’ve reviewed the workflows and spotted a few things worth tightening up. Please take these constructively:

Rather than scraping objo.dev/download and constructing filenames, the workflows can use stable.json (https://objo.dev/releases/stable.json). It provides the current version, exact download URLs, filenames, and SHA-256 checksums.
The Windows cold-cache path currently requests Objo-Studio-<version>-windows-x64.zip; the published portable archive is named Objo-Studio-<version>-win-x64-portable.zip. Existing successful runs appear to be benefiting from the pre-populated cache.
The macOS workflow currently ignores the output-directory input and always uses $HOME/Documents/ObjoPublisher.
Before users pass licence keys and signing credentials to these workflows, I’d add versioned releases and have examples reference a tag or commit rather than @main. Pinning the actions used internally would also strengthen the trust boundary.
Licence deactivation should ideally be a separate if: always() step so it still runs if something fails after activation or a publish step is cancelled.
Microsoft’s current signing action is Azure/artifact-signing-action@v2, and their recommended authentication method is OIDC. Timestamping should probably be required for distributable Windows packages.
The experimental Objo-signing Windows workflow has a couple of YAML structural issues, and the example currently defines download-windows-artifact twice. That fits with your note that this path has not yet been fully tested.

The underlying idea and overall structure are excellent, and this is an impressive demonstration of what can already be automated with Objo.

I’d be very happy to help test this, clarify the supported Objo download and publishing contracts, and work through any CLI improvements that would make CI integration easier. This is a genuinely valuable contribution to the Objo ecosystem.

madamov

Garry Thanks for nice words. I will try to address things you listed in next few days.

My goal is to replicate everything what I am already doing while developing in 4D where I am using GitHub for everything project related. Each issue is addressed in new branch, it is merged back through Pull request where PR description goes into release notes (for some projects I use conventional commits for that). Releases builds macOS and Windows (and will Linux) packages using actions like those described here, uploads it to SFTP server into a folder accessible to clients over https URL.

That is saving me so much time than building locally. 4D matured enough over the years that we could develop on macOS only firing Windows virtual machine when I need to check GUI visual appearance , which I know it will be the case with Objo Studio, if it is not already.

madamov

Garry

I’ve now addressed all of the points you raised:

Switched from scraping objo.dev/download to using stable.json for version detection and download URLs.
Added support for both the latest release and user-requested versions while still benefiting from versioned caching.
Fixed the Windows portable download to use the correct published archive.
Corrected the macOS workflow so output-directory is now honored.
Added versioned releases (v1) and updated the examples to reference tagged releases instead of @main.
Moved license deactivation into separate if: always() cleanup steps across all workflows.
Updated the Azure Trusted Signing workflow to use Microsoft’s official Azure/artifact-signing-action@v2.
Fixed the YAML issues in the experimental Windows signing workflow and cleaned up the example workflows.

The only item I haven’t been able to complete fully is migrating to the recommended OIDC authentication flow for Azure Trusted Signing. At the moment I only have limited access to the Trusted Signing account and certificate profiles provided by another organization. I don’t have sufficient permissions to reconfigure the Azure application or its authentication model, so I’m currently limited to the existing service principal credentials they’ve provided. I do not have company or some entity in EU, I do in Serbia, even though I hold Slovenian citizenship too. I will ask my uncle if I can use his LLC for this because I don't think Microsoft will grant EU individuals to use Trusted Signing in near future. First I need to get him domain and site, he is old school owner of construction company, doesn't use internet at all. B) Apple is better in signing and notarisation process, I've registered my company as Team more than 10 years ago, provided DUNS number and got approved in two days.

Calling workflows now demonstrates how to upload downloaded artefacts to SFTP server. I will move this to reusable workflows in next release having destination as option.

Garry

This is fantastic, @madamov. I’m honestly blown away that you’ve worked through every point so quickly and thoroughly. You haven’t merely patched a few issues, you’ve turned this into a properly versioned, reusable workflow set with safer cleanup and clearer examples. Adding the SFTP deployment example already is another lovely touch.

Please don’t feel that you need to rearrange company matters just to solve OIDC for this. The limitation is completely understandable and clearly documented. OIDC can come later if and when your Azure access makes it possible.

What means the most to me is seeing someone bring this much energy, care, and real-world experience to Objo. This is exactly the kind of community contribution I hoped Objo might inspire, and I’m genuinely grateful. `ObjoPublisher is a valuable addition to the ecosystem.

Thank you, not only for building it, but for responding so positively and thoughtfully to the feedback. Please keep telling me where Objo or its CLI makes this harder than it ought to be. I want the official tooling to support work like yours as well as possible.