* Completed List cmd and added API calls * Minor comments and add delete code to pass linting * Typo in descriptions * Minor comments * Validations * Validations-1 * improved branch flag validation * removed build * working after refactory with bad names * Command working, test not working * Corrected creation of service * Finalized structure using service * Deleted tests * cleanup * cleanup * cleanup * removed space with tab * aligned types in model.go * Update model.go * resolved comments * Refactor * removed long descriptions * Working incomplete tests * Completed tests * cleanup * checks * CI and release workflows * PR comments * PR comments * minor comment issue * minor comment issue * updated tests to work with workflow * Updated tests to support new option service * Improved eror handling for list * Improved error handling * Printing error in restclient * Nil in rest client * reverting changes * Release.md * Updates docs * Updates docs * Upgraded go-gh * added env in workflow * reusing rest client error * reusing sankalps fix for windows workflow * Revert "reusing sankalps fix for windows workflow" This reverts commit dfb1a94305b94b16a720bff599dba755f4a96175. * Other imp files for release * security.md * Updated contribution guidelines * Updated numberings to start with 1 * Update README.md (#15) * Update README.md * Update README.md * Update README.md * Updated contributing.md Co-authored-by: Sankalp Kotewar <kotewar@github.com> Co-authored-by: Bishal Prasad <bishal-pdmsft@github.com>
2.1 KiB
Releasing
Our build system automatically compiles and attaches cross-platform binaries to any git tag named vX.Y.Z. The changelog is generated from git commit log.
Users who run official builds of gh on their machines will get notified about the new version within a 24 hour period.
To test out the build system, publish a prerelease tag with a name such as vX.Y.Z-pre.0 or vX.Y.Z-rc.1. Note that such a release will still be public, but it will be marked as a "prerelease", meaning that it will never show up as a "latest" release nor trigger upgrade notifications for users.
General guidelines
- Features to be released should be reviewed and approved at least one day prior to the release.
- Feature releases should bump up the minor version number.
Tagging a new release
git tag v1.2.3 && git push origin v1.2.3- Wait several minutes for builds to run: https://github.com/actions/gh-actions-cache/actions
- Verify release is displayed and has correct assets: https://github.com/actions/gh-actions-cache/releases
- Scan generated release notes and optionally add a human touch by grouping items under topic sections
- (Optional) Delete any pre-releases related to this release
If the build fails, there is not a clean way to re-run it. The easiest way would be to start over by deleting the partial release on GitHub and re-publishing the tag. Note that this might be disruptive to users or tooling that were already notified about an upgrade. If a functional release and its binaries are already out there, it might be better to try to manually fix up only the specific workflow tasks that failed. Use your best judgement depending on the failure type.
Release locally for debugging
A local release can be created for testing without creating anything official on the release page.
- Make sure GoReleaser is installed:
brew install goreleaser goreleaser --skip-validate --skip-publish --rm-dist- Find the built products under
dist/.