Add composite GitHub Action for modctl build workflow (#507)

[rishi-jat]

Summary

This change introduces a composite GitHub Action to streamline the use of modctl in GitHub Actions workflows.

The action installs modctl (latest or pinned version), builds a model artifact from a Modelfile, and optionally performs registry authentication for remote artifact output.

Key points:

• Adds root-level action.yml implementing a composite action
• Supports modctl installation via official release tarballs with OS/arch resolution
• Exposes build configuration through inputs:
  • artifact_name (required)
  • modelfile_path
  • context_path
  • modctl_version
• Provides optional registry integration via modctl login
  • Login is executed only when registry, username, and password are all provided
  • Fails fast on partial configuration
• Includes input validation and deterministic failure behavior

Validation:

• Adds .github/workflows/modctl-action.yml to exercise:
  • latest and pinned modctl versions
  • local action usage (uses: ./)
  • registry login execution path
• Uses pinned action SHAs to match repository conventions

Documentation:

• Updates README.md with minimal usage example
• Adds detailed GitHub Action documentation in docs/getting-started.md
  • input reference
  • version pinning
  • optional registry usage

Notes:

• Action is referenced via @main until a dedicated release tag is introduced
• Additional features (advanced flags, internal workflow adoption) can be iterated separately

Fixes #507

[gemini-code-assist]

Code Review

This pull request introduces a composite GitHub Action to automate the installation of modctl and the building of model artifacts, accompanied by updated documentation in the README and getting started guide. The review feedback identifies critical security risks related to shell injection and secret exposure when using GitHub Action expressions directly within shell scripts, advising that inputs and secrets be mapped to environment variables. Furthermore, there is a recommendation to replace brittle JSON parsing logic with more robust tools like the GitHub CLI or jq.

[Copilot]

Pull request overview

This PR introduces a composite GitHub Action (at the repo root) to install modctl and run modctl build in workflows, with optional registry login support, and adds docs + a CI workflow to exercise the action.

Changes:

• Added a root-level composite action (action.yml) that installs modctl, optionally logs into a registry, and builds a model artifact.
• Added a dedicated workflow to validate the action against “latest” and a pinned modctl version and to execute the registry-login path.
• Updated README and getting-started docs with usage examples and input reference.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
action.yml	New composite action that validates inputs, installs modctl from GitHub Releases, optionally logs in, and runs modctl build.
docs/getting-started.md	Added a “GitHub Action” section documenting usage, inputs, version pinning, and optional registry integration.
README.md	Added a minimal action usage snippet and link to the detailed docs section.
.github/workflows/modctl-action.yml	Added CI workflow to exercise local action usage with latest/pinned versions and the registry-login execution path.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rishi-jat]

/cc @sabre1041
/cc @bergwolf
/cc @chlins

[sabre1041]

Thanks for submitting this contribution as it is the starting point for simplifying how users leverage ModelPack within their GitHub Actions Workflows. A few comments from my side

1. Recommend changing the output_remote variable to push to make it more explicit
2. There should be a way to determine the latest release version without the use of gh and the need for a GITHUB_TOKEN. Since the repository is already public, we should be able to determining the appropriate version without requiring credentials
3. If publishing (push=true), include an output parameter with the location of the remote artifact. It would be good to include the digest of the published artifact (not yet a feature in modctl but might be a good feature request

Actions are best placed in a separate repository so that they can have an independent lifecycle to the primary modctl artifact. If others think the same, we can look to create a separate repository