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.
We do have github integration but I think something clearly does not work. We should ask how it works on their discourse.
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
One needs to use sentry-cli to create releases and maybe it’s worth adding that to the release job on travis: https://docs.sentry.io/cli/releases/#sentry-cli-commit-integration
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 think thats ok, we should associate all releases one of and plumb that in the CI for future.
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.
I’ll back-tag all others tomorrow.
I does look a bit fishy tagging 3 month old commits into 1.2.0, but , maybe it will get better.
Alternative is to nuke everything, create the releases, and then repush the crash reports.
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.
This is like a totally interesting concept of what releases even are
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.
How much do we care about this?
I don’t care at all. This will be OK Eventually™.
I am curious to see if the “publish releases and stufF” build step will work.
I wonder if we can rerun some old release and see what happens?
Can you be patient until Tuesday? Then we can release 1.2.1-rc.1 and iterate it until it works. Running it now on 1.2.0 looks like it works.
@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?
I don’t think issue tagging will have any effect on this, they might get reopened if they come from an earlier version tho.
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
They are not ordered as calmh said we don’t care.
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).