GitHub Actions: markbind-action

GitHub Actions: markbind-action

Follow the steps below to get started on modifying the source code.

Setting Up

1. Fork the action repository.
2. Familiarise with the existing workflow syntax/options provided in the repository's README.md.
3. Set up a repository that contains a MarkBind site to test the action:
   1. Create a repository.
   2. Set up MarkBind and run markbind init to populate with default content.
   3. Push your repository to GitHub.
      • Example

Modifying the action

1. Create a new branch from master to work on your changes.
2. Make necessary modifications to the workflow files.
3. Update the repository's README.md to reflect the changes.

Testing the action

1. Include a workflow file in your to test your modified version of the action.
   • Instead of using uses: MarkBind/markbind-action@v2 in the workflow file, use uses: yourGithubName/markbind-action@yourBranch to reference the unpublished version of the action that you are currently developing.
     • e.g. uses: tlylt/markbind-action@main
2. Trigger the action as needed, check and validate the results in the action logs.

You can now submit PRs to improve MarkBind's GitHub actions! 🎉

Release Management

Based on the GitHub Actions documentation, we are using tags for release management.

• Create and validate a release on a release branch (such as release/v1) before creating the release tag (for example, v1.0.2).
• Create a release using semantic versioning. For more information, see "Creating releases."
• Move the major version tag (such as v1, v2) to point to the Git ref of the current release. For more information, see "Git basics - tagging."
• Introduce a new major version tag (v2) for changes that will break existing workflows. For example, changing an action's inputs would be a breaking change.