Skip to content

Update publish-custom-github-action.md #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 15, 2022
Merged

Update publish-custom-github-action.md #16

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions github/create-custom-github-actions/includes/publish-custom-github-action.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,8 @@ The `README.md` file is often the first place developers will look at to see how

As a general rule, the `README.md` file should include everything a user should know to use the action. If you think it could be useful information, include it in the `README.md`.

GitHub Actions lets you generate markdown files and publish them as a job summary. Using the same familiar functionality that powers pull requests and issues, an action can generate custom Markdown content on the run summary generated by each job.

## Release and version your action

If you're developing an action for other people to use, regardless of if it's public or private, you should define a release management strategy to control how updates are distributed. Major version updates including necessary critical fixes and security patches that affect compatibility need to be documented clearly.
Expand All @@ -37,6 +39,8 @@ If you're developing an action for other people to use, regardless of if it's pu

A good release management strategy should include versioning recommendations. Users should not be referencing an action's default branch with the action as the default branch which is likely to contain the latest code (which may or may not be stable) and could result in your workflow breaking. Instead, we recommend that users specify a major version when using the action, and to only direct them to a more specific version if they encounter issues. This can be done by configuring their GitHub Actions workflow to target a tag, a commit's SHA, or a specific branch named for a release. Let's take a closer look at these release options.

We’ve made changes in GitHub Actions to better support communities who have chosen to move away from using `master` as their default branch name. We have updated all of our starter workflows to use a new `$default-branch` macro. You can take advantage of this feature in your custom starter workflow templates as well. In addition, we have renamed the default branch for most of the GitHub-authored actions from `master` to `main`. All of your workflows that reference the old branch name will still work. You’ll see a prompt to change to the new name when you edit the workflow on the web.

#### Tags

Tags can be a good way to manage releases for an action. By using tags, users can easily distinguish between major and minor versions. Below is a list of helpful practices to consider when creating releases:
Expand Down