Use latest release of action of repository

[lx-wnk]

Why are you starting this discussion?

Product Feedback

What GitHub Actions topic or product is this about?

Workflow Configuration

Discussion Details

In #88510, someone asked how to use the latest version of an action. The OP accepted ‘use @main’ as the answer, but that doesn't really solve my problem – who really wants to base automated tasks on the main/trunk branch?
I also searched for other similar discussions, but couldn't find any – if there are any, please excuse the duplication!

In my case, I would like to always use the latest version/tag of an action container, such as ‘uses: $myCompany/$myRepository/actions/setup-php-project@latest’, instead of always manually incrementing my version, such as ‘uses: $myCompany/$myRepository/actions/setup-php-project@v0.3’.
In an internal company pipeline with many different repositories, it could simply be a pushed bug fix for the actions that should be used directly by all other repositories.

I may be on the wrong track to solve this problem (if so, please help me here) 🙂

Thanks in advance!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[GR0UD]

You’re right — @main is almost never what people want in production pipelines.

GitHub deliberately does not support @latest on actions (to avoid accidental breaking changes when a maintainer pushes a new tag).
The recommended pattern is:

YAMLuses: owner/repo/action@v1 # or @v1.2

Best solutions for “always get the latest stable”:

1. Use Dependabot (free) → it auto-creates PRs when a new tag is released.
2. For internal company actions only: tag with semantic versions and use a tiny GitHub Action that resolves @latest at runtime (there are community ones like docker://ghcr.io/.../update-action-tag).
3. Or pin to the major version and let Dependabot handle the rest.

This way you get automatic updates without the risk of @main.

[lx-wnk]

You are right, of course, that there are ways to solve the requirement independently – but my post was more about product feedback (suggestions for GitHub features and improvements). I would really like to see such a feature (even more if it might be possible to use ‘Semver constraints’, but that might be a bit too much) directly implemented.

The fact that Dependabot can also update the versions of the actions used (in case anyone else stumbles across this is actually new information for me - tbh. makes sense, but I didn't think of it). Thanks for the tip, I'll take a look!

[aleksadvaisly]

Agree, the "latest" pattern should be used whenever you have reoccurring event which is identified by ID.
For example if you have CI workflow, you should be able to refer to that by word "latest" instead of providing ID.
It would allow to refer that on different resources like README.md or static badge.

[Abdumajidov2005]

You are not on the wrong track — this is actually a common concern when working with GitHub Actions across multiple repositories.

Using @main or @master ensures you always get the latest version, but as you mentioned, it also introduces risk because a breaking change could immediately affect all pipelines. That’s why many teams avoid pointing automation directly to a moving branch.

A common approach is to use version tags combined with major version aliases. For example:

uses: myCompany/myRepository/actions/setup-php-project@v1

Then whenever you release a new compatible version (v1.2, v1.3, etc.), you simply move the v1 tag to point to the latest stable commit. This allows all repositories using @v1 to automatically receive non-breaking updates, while still protecting them from breaking changes introduced in v2.

Another option is to use tools like Dependabot or Renovate to automatically open pull requests when a new action version is released. This keeps versions explicit while still reducing manual maintenance.

So in practice, most teams choose one of these strategies:

• @main → always latest but risky
• @v1 (major version tag) → latest compatible release (most common)
• fixed tag (@v1.2.3) + Dependabot → safest and explicit updates

For internal company pipelines, the major version tag strategy (@v1) is usually the best balance between stability and maintainability.