Skip to content

Commit 952b525

Browse files
committed
update docs
1 parent ce5a8bc commit 952b525

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

README.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
# bcc-developer-docs-deploy
1+
# BCC Developerd Docs Deploy
22

33
## Updating the GitHub Action
44

@@ -26,20 +26,20 @@ The "version" of the Action (the `@v1` part) is just a tag that is added to a co
2626
This is the easiest approach. Use this if there are any breaking changes to the action, such as renaming an argument. Create a new tag with a comment like this:
2727

2828
```sh
29-
git tag -a -m "Action: Add argument" v2
29+
git tag v2
3030
```
3131

32-
This creates a `v2` tag with a comment of `Action: Add argument`.
32+
This creates a `v2` tag.
3333

34-
Then push the tag to GitHub (and any non-pushed commits) by appending the `follow-tags` flag to `git push`:
34+
Then push the tag to GitHub (and any non-pushed commits) flag to `git push`:
3535

3636
```sh
37-
git push --follow-tags
37+
git push origin v2
3838
```
3939

4040
After doing this, all the workflows in this and other repositories need to be updated to use that `v2` tag. This enables gradual adoption, but the downside is of course a potential burden of having to upgrade a lot of repositories.
4141

42-
### 2. Republish an existing tag
42+
### 2. Republish or delete an existing tag
4343

4444
By deleting and republishing the last tag, any future workflow will use the updated version without having to update all the other workflows. This is a **dangerous** action though, as an error in the configuration can lead to all repositories breaking, and you're deleting the tag from the server forever. **Only use this for backwards compatible changes**.
4545

0 commit comments

Comments
 (0)