This action builds WF WordPress projects, uploads the zipped artifacts to an AWS S3 Bucket and triggers the app creation and deployment on the desired AWS OpsWorks Stack.
Required The unique name of the web. Default "example2020"
.
Required The unique name of the client. (e.g. "example2020"
)`.
Optional OpsWorks app-name of the web. (e.g. "example_production"
)`.
Required The AWS S3 Bucket Name.
Required The database host to use.
The database slavehost to use.
Required The database name to use (e.g. example2020_production).
Required The database user to use (e.g. example).
Required The database password to use.
The deployment environment to use (e.g. staging). Default "production"
.
Required The deployment domain to use (e.g. "www.example.com,test.example.com"
)
Optional PHP timeout value
Optional PHP Version
Optional PHP memory limit
Optional maximum PHP upload filesize
Optional HTTPS redirect
Optional .html redirect
Optional WPML site key
Optional HTTP auth user
Optional HTTP auth password
Optional App specific AWS Access Key ID (set up as an OpsWorks environment variable).
Optional App specific AWS Secred Access Key (set up as an OpsWorks environment variable).
Required The AWS S3 Access Key ID for the deployment process.
Required The AWS S3 Secred Access Key for the deployment process.
The AWS S3 Region. Default "eu-west-1"
Required The AWS Opsworks Stack ID.
Required The AWS RDS instance ARN.
Optional remote api uri
Optional remote api user
Optional remote api password
uses: wunderfarm/wordpress-release-action@v4
with:
wf-webname: 'example2020'
wf-client: 'example2020'
app-name: 'example_production'
aws-s3-bucket: ${{ secrets.AWS_S3_BUCKET }}
database-host: ${{ secrets.APP_DB_HOST }}
database-slavehost: ${{ secrets.APP_DB_SLAVEHOST }}
database-name: 'example2020_production'
database-user: ${{ secrets.APP_DB_USER }}
database-password: ${{ secrets.APP_DB_PASSWORD }}
deployment-environment: 'staging'
deployment-domains: 'www.example.com,test.example.com'
php-timeout: '60'
php-version: '8.0'
memory-limit: '256M'
upload-max-filesize: '64M'
force-https: 'true'
app-wpml-site-key: ${{ secrets.APP_WPML_SITE_KEY }}
secondary-domains: 'www.example2.com,test.example2.com'
wf-auth-user: ${{ secrets.WF_AUTHUSER }}
wf-auth-password: ${{ secrets.WF_AUTHPASSWORD }}
app-aws-access-key-id: ${{ secrets.APP_AWS_ACCESS_KEY_ID }}
app-aws-secret-access-key: ${{ secrets.APP_AWS_SECRET_ACCESS_KEY }}
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: 'eu-west-1'
aws-opsworks-stack-id: ${{ secrets.AWS_STACK_ID }}
aws-rds-arn: ${{ secrets.AWS_RDS_ARN }}
remote-api-uri: ${{ secrets.REMOTE_API_URI }}
remote-api-user: ${{ secrets.REMOTE_API_USER }}
remote-api-password: ${{ secrets.REMOTE_API_PASSWORD }}
GitHub Actions will run the entry point from the action.yml. Packaging assembles the code into one file that can be checked in to Git, enabling fast and reliable execution and preventing the need to check in node_modules.
Actions are run from GitHub repos. Packaging the action will create a packaged action in the dist folder.
Run package
npm run package
Since the packaged index.js is run from the dist folder.
git add dist
Users shouldn't consume the action from master since that would be latest code and actions can break compatibility between major versions.
Checkin to the v1 release branch
$ git checkout -b v1
$ git commit -a -m "v1 release"
$ git push origin v1
Your action is now published!
See the versioning documentation