12/20/2023 0 Comments Teamcity release notesIf you have the Twitter account and the release isn’t a cake-in-your-face screwup fix that you’d rather no one ever heard about and want to just silently roll out to everyone during the night. You can use grt changelog v0.14.50 -md to get the change log with issue links in proper Markdown. Use the tag message as the template, make the header a link to the release, make the issue numbers to be links to the corresponding issues. Stable Releases - Create a post on the forum ¶ Create the GitHub release ¶įrom this point on we will work on secure.s.n, as the release user. If something failed in the build it’s hopefully “just” a flaky test - redo the build. We need the rebuild for those binaries to pick up the new tag. If not, jump in on the build server and trigger the Release/Syncthing job, for the release branch, while checking the options to rebuild all dependencies in the chain. If you are building a release candidate and fast forwarded the release branch the build server will already have started building it. We deliberately pushed the tags before the release branch, because the builder may start building the release branch immediately and needs to see the right tags at that point. If your remote spec is nondefault, tailor the push command to suit. Keep it around, keep it secure, upload the public part to a key server. If you don’t have one you’ll need to create one for the purpose. It should be your personal PGP key, whatever you would normally use. You will need your PGP key at hand for this step. The changelog file is the one you prepared previously. If there haven’t been any special releases or branching you can simply use the previous release as the starting point. First, find the commit hash or tag of the last commit on the previous release - changes since this point is what we are going to consider part of this release. To ensure that all closed issues are tagged with the milestone for the release you are doing, use the following command. The grt tool requires your GitHub token to manage milestones and issues you set the environment variable GITHUB_TOKEN while you are working on the release (but hopefully not all the time - programs can and do steal environment data). To our help we have the purpose written tool grt. We do however need to make sure that issues belong to the correct milestone, have the correct labels, and that the issue subject makes sense as a line in the change log. Most of the change log is machine generated from the closed issues. Release Candidates - Write a Change Log ¶ The stable release on the other hand requires a slightly different release process and is announced more widely. Candidate releases require work to prepare the changelog, which will just be reused for the stable release. The procedure differs sligthly depending on whether we’re doing a release candidate or a stable release. This means admin or maintainers group.Īn account on with sudo access.Ī TeamCity account on with deploy access. Push access to the repo, being able to bypass the pull request requirements. If you can’t build it, please don’t attempt to make a release of it. If you can build the project you are good to go. It doesn’t much matter which version of Go, we are not going to be building the release artifacts with it. In a pinch you can use as it has all the required tools installed, although you’ll need to add your git config, keys etc. If you know what you’re doing I’m sure it’s entirely possible to do it on Windows as well - but then you’re on your own. Macs and Linux boxes are good choices here. This is of course the default state at any given time.Ī normal computer (real or virtual) that has a command line and can run bash scripts. The main branch in a clean and buildable state, full of commits you are proud of and know the users will love. About ten minutes to half an hour of free time.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |