I would like my repo to have 2 functions:
Both require an action.yml in the repo. How do I combine them?
name: "Upload a Release Asset"
description: "Upload a release asset to an existing release on your repository"
author: "Github"
inputs:
upload_url:
description: "The URL for uploading assets to the release"
required: true
asset_path:
description: "The path to the asset you want to upload"
required: true
asset_name:
description: "The name of the asset you want to upload"
required: true
asset_content_type:
description: "The content-type of the asset you want to upload. See the supported Media Types here: https://www.iana.org/assignments/media-types/media-types.xhtml for more information"
required: true
outputs:
browser_download_url:
description: "The URL users can navigate to in order to download the uploaded asset"
runs:
using: "node12"
main: "dist/index.js"
branding:
icon: "package"
color: "gray-dark"
name: 'Hello World'
description: 'Greet someone and record the time'
inputs:
who-to-greet: # id of input
description: 'Who to greet'
required: true
default: 'World'
outputs:
time: # id of output
description: 'The time we greeted you'
runs:
using: 'docker'
image: 'Dockerfile'
args:
- ${{ inputs.who-to-greet }}
github/workflows directory in a repository, and a repository can have multiple workflows, each of which can perform a different set of tasks.
A reusable workflow is a pre-defined GitHub Actions workflow that can be called from another workflow. Reusable workflows make it easy to treat a workflow like an Action. It can be referenced and executed from other workflows in the caller's context.
The action. yml file describes your action and is called metadata file and uses the metadata syntax for GitHub Actions. Docker and JavaScript actions require a metadata file. The metadata filename must be either action. yml or action.
Workflows. A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.
The action.yml relies on seven metas, some of which are required, and others optional, as shown below: The name of your action. GitHub displays the name in the actions workflow run log and in the actions marketplace. The name of the action's author. A short description of the action.
Additional Resources / Info When you add the.yml file to your repository, you will see a new workflow appear in the Actions tab: You can then click on the Run workflow button and type in the command that you want to run. Here, GitHub Actions formatted the README file using Prettier and pushed it to the repository.
Action metadata files use the YAML syntax, identified by a .yml or .yaml extension. The action metadata file is named action.yml. If you're new to YAML, you can read more here. The action.yml relies on seven metas, some of which are required, and others optional, as shown below: The name of your action.
Every continuous integration service out of there supported at least YAML merge operator/anchors from the day 0, except github...this single limitation is forcing us to use external tools to workaround this otherwise you can easily end up with lot of duplicated code just to run simple operations. Have you ever heard about DRY?
@chenghopan! If you want to have two actions inside the same repository, they should be located in separate directories.
However, the action.yml
file is not required.
This file is only required for an action if you plan to list it in the GitHub Marketplace.
If you have the actions in the same repo, they can have their own action.yml
file located along with their Dockerfile or node script. Here's an example with two dockerfiles:
.
├── README.md
├── .github
│ └── workflows
│ └── main.yml
├── action1
│ ├── Dockerfile
│ ├── action.yml
│ └── entrypoint.sh
└── action2
├── Dockerfile
├── action.yml
└── entrypoint.sh
And here's a workflow in the same repo calling both actions in the same repo:
name: Test two actions
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: ./action1
- uses: ./action2
And here's a workflow in a different repo calling the actions:
name: Test two actions
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: managedkaos/github-actions-two-actions/action1@master
- uses: managedkaos/github-actions-two-actions/action2@master
If you're OK with not listing the actions in the GitHub Marketplace, just put the action.yml
file in the same dir as the action and you'll be fine!
For reference, you can find the code in these examples here:
Both require an action.yml in the repo. How do I combine them?
You could leave each of your actions in their own separate GitHub Action repository.
And, since August 2020, combine them.
See:
GitHub Actions: Composite Run Steps
You can now create reusable actions using shell scripts and even mix multiple shell languages in the same action.
You probably have a lot of shell script to automate many tasks, now you can easily turn them into an action and reuse them for different workflows. Sometimes it's easier to just write a shell script than JavaScript or Docker.
Now you don't have to worry about wrapping it up your scripts in a Docker containers.Here's an example of how you can use composite run steps actions:
workflow.yml:
jobs: build: runs-on: windows-latest steps: - uses: actions/checkout@v2 - uses: octocat/say-hello@v1 with: name: OctoCat
octocat/say-hello/action.yml:
inputs: name: description: 'Your name' default: 'No name provided' runs: using: "composite" steps: - run: echo Hello ${{ inputs.name }}. shell: bash - run: echo "Nice to meet you!" shell: pwsh
Learn more about composite run steps and visit the GitHub Actions community forum for questions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With