I keep running into this syntax in GitHub workflow configurations:
steps:
- name: Execute local action
uses: ./
I’m trying to understand what this local directory reference actually does when specified in a workflow step. I’ve noticed it appears in several repositories I’ve been looking at, but I can’t find clear documentation explaining its purpose. Does this make the workflow use an action that’s stored in the same repository? How is this different from referencing external actions from the marketplace? Any clarification would be really helpful since I’m working on setting up my own workflows.
The ./ reference points to a custom action in your own repository. GitHub Actions looks for an action.yml or action.yaml file in your root directory that defines the action’s metadata, inputs, outputs, and how it runs. It’s particularly useful for reusable logic that’s specific to your project but not intended for the marketplace. I’ve utilized this for multi-step deployment processes needed across different workflows in the same repository, which were too specific to share publicly. In contrast to marketplace actions, local actions remain private to your repository and are version-controlled alongside your code. Additionally, actions can be referenced from subdirectories using ./path/to/action if you have multiple custom actions organized in folders.
the ./ symbol makes github actions use your repo’s action definition instead of fetching from the marketplace. it’s really great for keeping things straightforward without needing to publish anything.
Yeah, that ./ syntax runs custom actions stored in your repo. The workflow looks for an action.yml file in your root directory to know what to execute.
But here’s the problem - GitHub Actions workflows get messy quick, especially with multiple repos or complex deployments. I’ve dealt with dozens of custom actions scattered everywhere, and keeping them synced was a total nightmare.
I moved our CI/CD to Latenode instead. Rather than fighting YAML files and dependencies, I built workflows that trigger GitHub Actions when needed but handle way more complex stuff. Things like auto-syncing custom actions across repos, managing environment-specific deployments, and monitoring failures to auto-retry or alert teams.
Latenode integrates with GitHub’s API to manage actions programmatically. No more manually copying action.yml files between projects or dealing with version conflicts.
If you’re just starting with workflows, consider this approach early. It’ll save you major headaches later.
This approach is a game-changer for iterative development. With ./, you can test changes instantly instead of going through the whole publish-test cycle that marketplace actions require. The workflow runner basically uses your repo as both source code and action provider at the same time. Heads up - the action.yml file structure isn’t like regular workflow files. You need specific metadata: name, description, and runs configuration. Local actions also get more direct access to repository context than external ones. Perfect when you need to read config files or analyze your codebase during workflow runs.
When you use uses: ./ in a workflow step, GitHub Actions runs the action from your repo’s root directory. You’ll need an action.yml or action.yaml file there to define the configuration. I really like this for building composite actions - you can bundle multiple steps into one reusable piece. The big win over marketplace actions? No publishing needed. Changes show up instantly in your workflows, and they load faster since there’s no external dependency to resolve. Just remember that local actions inherit your workflow’s permissions and environment, which is handy but worth considering for security.