-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 21.12.0 #1193
Comments
The changelog for tomorrow is actually going to be tricky because we don't have a PR related to #1196, and craft's auto mechanism assumes PRs/commits for every changelog entry. I read craft code and tested out putting an "Unreleased" section but that simply gets updated to the new version without actually listing all of the new material. |
What I am going to try is manually modifying the CHANGELOG.md on the Okay, plan C: Make a dummy PR related to the milestone in order to work with the existing changelog infra. |
Seeing these to account for: https://github.com/getsentry/self-hosted/milestone/8
https://github.com/getsentry/self-hosted/milestone/9
https://github.com/getsentry/self-hosted/milestone/10
Skip
Merp |
Changelog21.12.0Support Docker Compose v2 (ongoing)Self-hosted Sentry mostly works with Docker Compose v2 (in addition to v1 >= 1.28.0). There is one more bug we are trying to squash. By: @chadwhitacre (#1179) Prevent Component DriftWhen a user runs the By: @chadwhitacre (#1191), @aminvakil (#1186) React to log4shellSelf-hosted Sentry is not vulnerable to the log4shell vulnerability. By: @chadwhitacre (#1203) Forum → IssuesIn the interest of reducing sources of truth and restarting the fire of the self-hosted Sentry community, we deprecated the Discourse forum in favor of GitHub Issues. By: @chadwhitacre (#1167, #1160, #1159) Rename onpremise to self-hosted (ongoing)In the beginning we used the term "on-premise" and over time we introduced the term "self-hosted." In an effort to regain some consistency for both branding and developer mental overhead purposes we are standardizing on the term "self-hosted." This release includes a fair portion of the work in code towards this, hopefully a future release will include the remainder. The effect of this as a self-hosted user will be that you will see orphaned blah blah blah you need to clean those up floo flah how By: @chadwhitacre (#1169) Add support for custom DotEnv fileThere are several ways to configure self-hosted Sentry and one of them is the By: @Sebi94nbg (#1113) Various fixes & improvements
|
Gosh shouldn't we link to the changelogs for all of the components, as well? I'm thinking of #1131. |
Milestones ready. |
@chadwhitacre you could have blocked the release, prepare locally, edit the Changelog in the release branch, and then finalize the release. I think we should document this process and potentially find a way to easily edit the changelog before it goes out. The issue is automation and manual editing are things are at odds so the best I can think of it is having a mechanism like you offered: allow having an Happy to dive into Craft code after a while if this sounds like a good idea. |
Sentry failure:
Presuming this has to do with the changelog. |
Snuba and Relay are out, fwiw. |
Here's the failing call: const created = await this.github.repos.createRelease(
createReleaseParams
); Here's the payload: const createReleaseParams = {
draft: false,
name: tag,
owner: this.githubConfig.owner,
prerelease: isPreview,
repo: this.githubConfig.repo,
tag_name: tag,
target_commitish: revision,
...changes,
};
|
https://github.com/getsentry/sentry/blob/releases/21.12.0/CHANGES#L32-L1701 Blech, forgot about getsentry/craft#327 tho. :( |
Okay, I did a little poking at getsentry/craft#327. I'm not going to try to engineer a fix for that atm. Also, I have a review on getsentry/craft#335, but I don't think I'm going to try to use that for this release, in the interest of minimizing variability. I think my plan at this point is to:
|
This is an excellent workaround. You can still use the publish flow for this.
Is this because of the wrong merge base? |
Yes, it will use the existing branch. |
Meaning "Re-accept [the publish ticket]"?
Yes. |
CI is green for the CHANGES repair on the branch, I reaccepted the ticket. Technically this will be a different artifact than what we uploaded to PyPI and Docker, but the only delta is in the changelog so meh. |
Was about to say ... need to whack the old |
Here's the original 21.12.0 tag for reference. |
It was probably in a Slack thread that is gone now. Reason to do this here in GitHub instead. |
Oh gosh, I think I ended up recreating the release object in GitHub manually? And it was a total cluster? |
Yeah it was last month, this one has my name on it: |
Sweet! Slack thread still exists! 👍 |
Going to do the same here. |
Failed again ... |
Forgot to remove the tag. |
Made it past GitHub. 👍 |
Okay! Relay is really out this time. |
Back to self-hosted ... |
Exfiltrating the steps to recover from "Cannot upload asset" for
Then I discovered getsentry/craft#327. |
Oh right #1171 ... |
Oh right it was missing relay 21.12.0 ... 😅 |
Green! Re-accepting getsentry/publish#704 ... |
Done. |
Post-MortemThis was anecdotally the most difficult self-hosted release since I started a year ago. Issues:
General pattern: something something tags something something. I feel like a number of failure modes end up with us having to recreate a tag, and this can actually be catastrophic (inc-87) ... getsentry/craft#336 |
This looks like some terrible GitHub mishap. I actually got the Relay release email so my guess is either the job or the logs are corrupted. I'd file a support ticket with a link so they can investigate before the logs disappear.
I don't think you need an extra step for this as Craft should crash itself causing the job to fail. If the release is out, self-hosted release would fail anyway.
I think this process needs to be documented and maybe even streamlined. |
Done. I cc'd you. 👍
Yeah, that's in fact how I noticed that relay had not succeeded (even though it seemed it had). Hopefully a rare case. Not a big action item here more just a note to self.
|
Sharing out GH support thread for posterity:
Even if it is a system-level timeout or reaper, it seems that they are making us responsible for the container taking so long. Leaving this here for future discoverability in case of a repeat, but I don't think we need to take any further action now. |
My original post to them for context:
|
22.1.0
This release carries more risk than usual because of #796. I'm making a ticket here to remember some things to pay attention to.
sentry
release, make sure that the status provider check lines up name-wise with the check as named in GCB (see this thread)The text was updated successfully, but these errors were encountered: