This repository is a collection of reusable workflows and composite actions, specifically designed for use in wayofdev projects.
These tools encapsulate common and repetitive tasks, allowing for easy integration into multiple projects. This approach not only reduces the need to rewrite code but also ensures standardized operations across all Wayofdev repositories.
- Getting Started
- Composite Actions
- Workflows
- Security Policy
- Contributing
- Social Links
- Contributors
- Useful Resources
- License
To use these workflows and actions, reference them directly from your project's workflows. Detailed instructions for each are provided below.
Composite Actions are a powerful feature of GitHub Actions that allow you to create reusable actions using a combination of other actions, shell commands, or both.
This enables you to encapsulate a sequence of steps into a single action, making your workflows more modular, easier to maintain, and reducing duplication across your projects.
Composite Actions can accept inputs and use outputs, making them highly flexible and adaptable to various use cases.
Check each action's README file for detailed instructions on how to use it.
Action | Description |
---|---|
composer/get-cache-directory |
Gets the Composer cache directory path and exports it as env variable. |
composer/get-root-version |
determines the Composer root version based on the specified branch and exports it as env variable. |
composer/install |
Installs dependencies with Composer based on the specified dependency level. |
phive/install |
Install dependencies with Phive. |
playwright/install |
Installs Playwright along with its dependencies. |
pnpm/install |
Installs mono-repository dependencies using PNPM. |
s3/cache |
Cache artifacts, or restore them using S3. |
Read more about reusing workflows.
Automatically applies labels to pull requests based on modified paths.
This workflow triages pull requests and applies labels based on the paths that are modified in the pull request. This can help to categorize your pull requests and make it easier to identify the type of changes included.
To use this workflow, set up a .github/labeler.yml
file with your configuration in your project. For more information on how to configure the labeler, see: https://github.com/actions/labeler/blob/master/README.md
Here is an example of how to use this workflow:
.github/workflows/apply-labels.yml
---
on:
pull_request:
name: π·οΈ Add labels
jobs:
label:
uses: wayofdev/gh-actions/.github/workflows/apply-labels.yml@master
with:
os: ubuntu-latest
secrets:
token: ${{ secrets.GITHUB_TOKEN }}
...
.github/labeler.yml
---
"type: bug":
- head-branch: ['^bug', '^fix', 'bug', 'fix']
"type: enhancement":
- head-branch: ['^feature', '^feat', 'feature']
"type: documentation":
- changed-files:
- any-glob-to-any-file: ['assets/**/*', '.github/*', './*.md']
"type: maintenance":
- changed-files:
- any-glob-to-any-file: ['tests/**/*', '.github/workflows/*']
...
Real-world examples can be found in the wayofdev/laravel-package-tpl
repository.
This workflow automatically merges releases. This workflow utilizes peter-evans/enable-pull-request-automerge to auto-merge releases that are created by googleapis/release-please.
Here is an example of how to use this workflow:
.github/workflows/auto-merge-release.yml
---
on: # yamllint disable-line rule:truthy
pull_request:
permissions:
pull-requests: write
contents: write
name: π€ Auto merge release
jobs:
auto-merge:
uses: wayofdev/gh-actions/.github/workflows/auto-merge-release.yml@master
with:
os: ubuntu-latest
pull-request-number: ${{ github.event.pull_request.number }}
actor: lotyp
merge-method: merge
secrets:
# to trigger other workflows, pass PAT token instead of GITHUB_TOKEN
token: ${{ secrets.PERSONAL_GITHUB_TOKEN }}
...
Real-world examples can be found in the wayofdev/laravel-package-tpl
repository.
This workflow creates a release based on changesets. This workflow utilizes changesets/action to create a release based on changesets.
Here is an example of how to use this workflow:
.github/workflows/create-changesets-release.yml
---
on: # yamllint disable-line rule:truthy
push:
branches:
- master
name: π¦ Create release or publish to pnpm
jobs:
release:
uses: wayofdev/gh-actions/.github/workflows/create-changesets-release.yml@master
with:
node: 18
repository: wayofdev/next-starter-tpl
secrets:
# to trigger other workflows, pass PAT token instead of GITHUB_TOKEN
token: ${{ secrets.PERSONAL_GITHUB_TOKEN }}
npm_token: ${{ secrets.NPM_TOKEN }}
...
Real-world examples can be found in the wayofdev/next-starter-tpl
repository.
This workflow builds a docker image and pushes it to the Docker Container Registry.
Example repositories, using this workflow:
Build image with "release" tag:
.github/workflows/build-release.yml
---
on: # yamllint disable-line rule:truthy
release:
types:
- released
name: π Build docker images with release tag
jobs:
prepare:
runs-on: "ubuntu-latest"
outputs:
matrix: ${{ steps.matrix.outputs.matrix }}
version: ${{ steps.version.outputs.version }}
steps:
- name: βοΈ Generate matrix
id: matrix
run: |
echo 'matrix={
"os_name": ["alpine"],
"php_version": ["8.1", "8.2"],
"php_type": ["fpm", "cli", "supervisord"]
}' | tr -d '\n' >> $GITHUB_OUTPUT
- name: βοΈ Get version for image tag
id: version
run: |
version=${{ github.ref_name }}
version=${version#v}
echo "version=$version" >> $GITHUB_OUTPUT
build:
needs: prepare
strategy:
matrix: ${{ fromJson(needs.prepare.outputs.matrix )}}
uses: wayofdev/gh-actions/.github/workflows/build-image.yml@master
with:
os: "ubuntu-latest"
push-to-hub: true
image-namespace: "wayofdev/php-base"
image-template-path: "./dist/base"
image-template: ${{ matrix.php_version }}-${{ matrix.php_type }}-${{ matrix.os_name }}
image-version: ${{ needs.prepare.outputs.version }}
secrets:
docker-username: ${{ secrets.DOCKER_USERNAME }}
docker-password: ${{ secrets.DOCKER_TOKEN }}
...
Real-world examples can be found in the wayofdev/docker-node
repository.
This workflow leverages the codesee-io/codesee-action action to automatically generate architecture diagrams for your codebase whenever a pull request is made.
CodeSee is an open-source tool that helps visualize your codebase and its dependencies, making it easier for new contributors to understand the project or for maintaining a clear view of your project's architecture over time.
Here is an example of how to use this workflow:
.github/workflows/create-arch-diagram.yml
---
on: # yamllint disable-line rule:truthy
push:
branches:
- develop
pull_request_target:
types:
- opened
- synchronize
- reopened
name: π€ CodeSee
permissions: read-all
jobs:
codesee:
uses: wayofdev/gh-actions/.github/workflows/create-arch-diagram.yml@master
with:
os: ubuntu-latest
continue-on-error: true
secrets:
codesee-token: ${{ secrets.CODESEE_ARCH_DIAG_API_TOKEN }}
...
Real-world examples can be found in the wayofdev/laravel-package-tpl
repository.
This workflow uses redhat-plumbers-in-action/differential-shellcheck to run shell script analysis.
Here is an example of how to use this workflow:
.github/workflows/shellcheck.yml
---
on: # yamllint disable-line rule:truthy
pull_request:
name: π Differential shell-check
permissions:
contents: read
jobs:
shellcheck:
uses: wayofdev/gh-actions/.github/workflows/shellcheck.yml@master
with:
os: ubuntu-latest
severity: warning
secrets:
token: ${{ secrets.GITHUB_TOKEN }}
...
Real-world examples can be found in the wayofdev/laravel-package-tpl
repository.
This project has a security policy.
Thank you for considering contributing to the wayofdev community! We are open to all kinds of contributions. If you want to:
- π€ Suggest a feature
- π Report an issue
- π Improve documentation
- π¨βπ» Contribute to the code
You are more than welcome. Before contributing, kindly check our contribution guidelines.
- Twitter: Follow our organization @wayofdev and the author @wlotyp.
- Discord: Join our community on Discord.
-
Composite Actions vs Reusable Workflows: what is the difference?
-
cycle/gh-actions β Downstream repository of reusable GitHub Actions for Cycle organization.
-
ergebnis/.github β Shareable actions of the @ergebnis organization.
-
skills/reusable-workflows β Reusable workflow examples