Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
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
25 changes: 25 additions & 0 deletions docs/action-versioning.md
Original file line number Diff line number Diff line change
@@ -1,2 +1,27 @@
# Versioning

Actions are downloaded and run from the GitHub graph of repos. The workflow references an action use a ref.

Examples:

```yaml
steps:
- use: actions/setup-node@74bc508
- user: actions/setup-node@v1
- uses: actions/setup-node@master
```

Binding to the immutable sha1 of a released version is the safest for stability and security.

Binding to a specific major version allows for receiving critical fixes and security patches while still mainting compatibility and the assurance your workflow should still work.

Binding to master is convenient but if a new major version is release which breaks compatilibility, your workflow could break.

# Recommendations

1. **Create a release**: use sematic versioning for the release (v1.0.9)
2. **Update the major version tag**: move the major version tag (v1, v2, etc.) to point to the current release.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be helpful to link out to something like https://git-scm.com/book/en/v2/Git-Basics-Tagging here (coming from someone who isn't very familiar with git tagging).

Also, my understanding was that tags point to refs, can one point to a release? Might be helpful to include some commands here as well (e.g. git tag -fa v1)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a release creates a tag. So I would create a release for v1.0.9 but then point the v1 tag to the ref that v1.0.9 pointed to. Right?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that sounds right to me. Maybe reword to "point to the ref of the current release"? And then the full command would be git tag -fa v1 <commit of release>. Or, if the current release matches what is checked into master, then just git tag -fa v1

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion. Done.

3. **Compaitbility Breaks**: introduce a new major version tag (v2) if changes will break existing workflows. For example, changing inputs.



2 changes: 1 addition & 1 deletion docs/node12-action.md
Original file line number Diff line number Diff line change
Expand Up @@ -107,7 +107,7 @@ $ git add <whatever only files you added>
$ git commit -m "Message"
```

> NOTE: husky will add/vendor node_modules and prune dev dependencies. See husky in package.json for details. There is no need for you to add node_modules.
> husky will add/vendor node_modules and prune dev dependencies. See husky in package.json for details. There is no need for you to add node_modules.

# Publish Action

Expand Down