| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
🦋 Changeset detectedLatest commit: 39422af The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Sorry, something went wrong.
There was a problem hiding this comment.
Amazing. Changes look good to me, the logic seems fine. Description matches the behaviour.
Do we have any tests yet for the actions?
Sorry, something went wrong.
|
Our tests currently is very loose. We should get to that after we're finished with most of the big changes I think. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
fix #247
fix #547
NOTE: the above issues requested documentation improvements, but I have not done them here yet. I think probably it's easiest to consolidate all the docs update once we've finished reworking the actions & sub-actions.
Possible alternatives
1. I wonder if it should be push-git-tags instead of create-git-tags, because we'd actually only do the pushing. (renamed)
This is a breaking change because create-github-releases: false previously also disabled push tags, but now it'd push by default, unless set push-git-tags: true explicitly.
We can kinda prevent this breaking change by making push-git-tags always follow the value of create-github-releases, unless push-git-tags was explicitly set, but I feel it's a bit hard to follow compared to the current behaviour, where both are independent options, just that create-github-releases: true will always force push-git-tags: true because inherently that's how github releases work.
Or we support some sort of create-github-releases: "tag-only" but this also seems a bit weird.