Marketplace actions

[sudoUgando]

If you find an action on the Marketplace that does 80% of what you need, what are your options for extending or customizing the remaining 20%?

[EimanTahir027]

If you find an action on the Marketplace that does 80% of what you need, what are your options for extending or customizing the remaining 20%?

Great question. When a Marketplace action covers most of what you need but not everything, you have several options for filling the gap without writing everything from scratch.

Options for extending a Marketplace action

1. Fork and modify

Clone the action's repository, make your changes, and reference your fork in the workflow:

- uses: your-username/action-name@v1.2.3

Best when the missing functionality is fundamental to the action's behavior and unlikely to be upstreamed. Downside: you now maintain the fork and miss upstream updates.

2. Wrap it in a composite action

Create your own action that calls the Marketplace action as a step, then adds your custom steps afterward:

# .github/actions/my-custom-action/action.yml
runs:
  using: composite
  steps:
    - uses: marketplace/action@v1
    - run: ./custom-cleanup.sh
      shell: bash

This is often the cleanest approach — you get upstream updates automatically and only maintain your wrapper layer.

3. Use outputs and post-processing

Many actions expose outputs. Capture those and use them in subsequent steps:

- id: base-action
  uses: some/action@v1
- run: |
    # Transform or extend the output
    echo "modified=${{ steps.base-action.outputs.result }}" >> $GITHUB_ENV

4. Inject environment or input overrides

Some actions accept env: or custom input fields that let you configure behavior the author didn't explicitly parameterize. Check if the action reads environment variables or has hooks for pre/post scripts.

5. Layer with a script step

Run the action, then add inline shell or Node.js steps after it to handle the remaining logic. This works well for edge cases like reformatting output, sending custom notifications, or conditionally skipping downstream jobs based on results.

6. Open a PR or request an input

If your customization is generic, consider contributing the feature back. Many action authors appreciate PRs that add optional inputs or hooks.

---

My typical approach: Option 2 (composite action wrapper) for anything I'll reuse across workflows, or Option 5 (inline script step) for one-off customizations. Forking is a last resort — it cuts you off from upstream fixes and features.