These are metrics I receive from some of my vmagents: vm_app_version{instance="…", job="vmagent", version="vmagent-20230313-062416-16be82b"} vm_app_version{instance="…", job="vmagent", version="vmagent-20230407-010449-tags-v1.90.0-0-gb5d18c0d2", short_version="v1.90.0"} vm_app_version{instance="…", job="victoria-metrics", version="victoria-metrics-20230816-130821-tags-v1.93.0-0-g59f7d810c", short_version="v1.93.0"} ("version" doesn't have tag info, and "short_version" is missing altogether) The first comes from the Ports (not the most recent, but it's the same), the second is a Windows build, the third is running on FreeBSD but compiled manually (git clone + gmake). I wonder / I guess it would be enough to use a build tag like this in the Makefile: BUILDINFO_TAG=tags-v1.93.0-0-g59f7d810c Ah, yes, I checked with a local build and it seems to be enough: vm_app_version{version="vmagent-20230812-130110-tags-v1.93.0-0-g59f7d810c", short_version="v1.93.0"} I can produce a patch if desired, but I simply changed PORTVERSION, BUILDINFO_TAG, make gomod-vendor, make makesum, make install. PS: 1.93 is the new LTS after 1.87.
By the way v1.93.0 can also build bin/victoria-logs, it's a replacement for ElasticSearch used for logs, and it could be a new child port as simple as the current vmutils. https://docs.victoriametrics.com/VictoriaLogs/
I attempted a more complete patch here: https://github.com/lapo-luchini/FreeBSD-Ports/commit/2ac73d1708822ca269eb12a2a7e658eb9bda2438.patch I also exluded the `%%DOCSDIR%%/VictoriaLogs/*` folder too, I guess it will be included in the specific sub-port.
Beware: hotfix 1.93.1 has been released. https://github.com/lapo-luchini/FreeBSD-Ports/commit/f699306bbdb19ad3bbca4a60136ed68bb00db1c4
1.93.2 is out too. :) (but 1.93.1 fixes a very bad bug that under rare circumstances leads to losing gheaps of data, 1.93.2 is minor, AFAICT)
> I guess it would be enough to use a build tag like this in the Makefile: > BUILDINFO_TAG=tags-v1.93.0-0-g59f7d810c So basically you mean that current BUILDINFO_TAG=<short-git-hash> should be changed to "tags-v${PORTVERSION}-0-g<short-git-hash>"? What does that middle -0- zero mean? > victoria-logs [is] a replacement for ElasticSearch used for logs, and it > could be a new child port as simple as the current vmutils. I wonder if we could include this utility as part of vmutils rather than creating another port just for one more program. > Beware: hotfix 1.93.1 has been released. I've asked Oleg earlier what thinks about if/when shall we move to v1.93.x, but he hadn't replied yet, I'll CC him from this PR as well. Based on your and others' input I reckon we should probably update.
> What does that middle -0- zero mean? It means "0 commits ahead of the specified tag", so basically "exactly that tagged version". > I wonder if we could include this utility as part of vmutils rather than creating another port just for one more program. Mhhh, I don't think that's the best approach, because victoria-metrics is the main program, vmutils are "utils for victoria-metrics", but victoria-logs is a totally separated program (while being done by the same authors and sharing most of the codebase, up to the point of living in the very same repository): Victoria Metrics is an alternative to Prometheus/InfluxDB (used for metrics), while victoria-logs is an alternative to ElasticSearch/GrafanaLoki (used for logs).
> tags-v${PORTVERSION}-0-g<short-git-hash> Yes, exactly! It is a standard format for git version releases. (I have a personal dislike for the "g" prefix on the hash, but it's there on the official builds so I think it's better to mimic the exact format for FreeBSD releases too)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3a5b4a932dfa0c255c69d074703edaf0ca2bc738 commit 3a5b4a932dfa0c255c69d074703edaf0ca2bc738 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2023-09-22 11:29:40 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2023-09-22 11:29:40 +0000 net-mgmt/victoria-metrics: update VictoriaMetrics to version 1.93.5 While here, set the BUILDINFO_TAG tag to what upstream does so that version is reported properly in the logs (see PR). Reported by: portscout PR: 273257 Submitted by: Lapo Luchini net-mgmt/victoria-metrics/Makefile | 7 +- net-mgmt/victoria-metrics/Makefile.deps | 59 ++++++++------- net-mgmt/victoria-metrics/distinfo | 124 +++++++++++++++----------------- net-mgmt/victoria-metrics/pkg-plist | 79 ++++++++++++++++++-- 4 files changed, 165 insertions(+), 104 deletions(-)
(In reply to Lapo Luchini from comment #6) > I don't think that's the best approach, because victoria-metrics is the main > program, vmutils are "utils for victoria-metrics", but victoria-logs is a > totally separated program Fair enough. > and it could be a new child port as simple as the current vmutils. Yeah, I'll do it, thanks!
(In reply to Lapo Luchini from comment #1) > By the way v1.93.0 can also build bin/victoria-logs, it's a replacement > for ElasticSearch used for logs, and it could be a new child port as > simple as the current vmutils. On the other hand, while it is built from the same repo, it seems that upstream they're using a different versioning. Victoria Logs v0.4.2 was tagged 2023-11-15, sequentially between tags for Victoria Metrics 1.93.7 and .8: % git tag --format='%(creatordate:short)%09%(refname:strip=2)' | sort 2023-10-16 v1.93.6 2023-11-01 v1.93.7 2023-11-15 v0.4.2-victorialogs 2023-11-15 v1.93.8 2023-12-10 v1.93.9
(In reply to Lapo Luchini from comment #10) > On the other hand, while it is built from the same repo, it seems that > upstream they're using a different versioning. Yeah, that was the thing I stumbled upon which made the logs ports not quite fit as the slave for the main VictoriaMetrics port, and didn't figure how to deal with this discrepancy. Eventually, someone else stepped in and created the independent port (as of commit ports 52e5fa8e7955), so I guess we can close this PR.