It looks like sentry doesn’t understand semver or care about the “name of versions” in any way, just about time. I marked some stuff as fixed in version v1.2.0-rc.1 and as soon as the next event comes in sentry marks it as a regression in v1.1.3. On sentry the latter is listed higher than the former, so I think it considers it as newer.
The releases page on sentry says we need to associate commits with releases and docs say that can be done with a github integration at organization level - which I don’t have access to. Is that setup and just not working? Alternatively this info could also somehow be attached in CI at build time.
I think one can manually create releases, or it does so automatically on first seeing it. The creation order then becomes the release order. Currently this is broken because we’re getting reports from old versions. In the future the problem should go away as we should not be getting new reports from the past.
Btw, this … exceeds my expectations.
root@data:~# df -h /mnt/crash_reports
Filesystem Size Used Avail Use% Mounted on
/dev/sda 9.8G 2.4G 6.9G 26% /mnt/crash_reports
If you want releases associated with commits, you need to do that manually, despite the integration. With integration you just don’t need to specify the commit, but can use an --auto flag. I do not understand why sentry doesn’t just try that when it automatically creates a release… https://forum.sentry.io/t/github-integration-doesnt-associate-commits/6542/9
In the mean time as updates to 1.2.0 will happen for a long time, so I am pretty sure panic reports with “new old versions” will keep popping up. That means the nice feature to mark an issue as resolved in a specific version, and thus get notified if the issue comes up in a newer version, is unusable. The only workaround I see would be to run a little script that creates and associates all releases (e.g. >0.14) with sentry-cli, which is a bit annoying.
I’ve plumbed that into CI, so next release it should tag commits and stuff properly, as long as the VCS checks out the right branch in the release build.
It’s probably because 1.2.0 is an older release than 1.1.4 in terms of creation time, and even tho the commits were associated with 1.1.4, it thinks that 1.2.0 is a branch of the same point.
It kind of makes sense, as it does not know that 1.2.0 is ahead in the tree, as you checkout 1.1.4 and say this is 1.1.4.
If 1.1.4 is later than 1.2.0, it must be a branch of some sorts.
It seems I can fudge the release dates to bring peace to the world in SQL, yet parsing semver + handling RCs in SQL is not so much fun.
@AudriusButkevicius Will I wreak havoc again if I start to tag issues as fixed in e.g. v1.2.0-rc.1 already now? I.e. should I hold off on anything version related until you worked all of this out or can I just use versions and report if it doesn’t work as expected?
The 1.2.0 releases are still not ordered correctly. Sentry just marked the cluster config stuff as a regression in 1.1.1 after I marked it as resolved in 1.2.0. Unless it’s trivial to fix, we can also just wait for 1.2.1 on Tuesday (?) and mark everything fixed in 1.2.0 as fixed in 1.2.1
What did you do then? All the other releases now look like their properly ordered (by creating date, but still that wasn’t the case before you did something).
, maybe it will get better.