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