Building tagged versions if packages

[GurliGebis]

I was wondering, is there a way we can make Jenkins build a specific tag for the packages?

If possible, then we would be able to build 1.4.0 (with the latest Debian updates ofcourse).

[dd010101]

Yes you can, not easily though, but that would be misleading. Fixating on specific version is bad because whatever version you think you getting you won't really get. Could you build 1.4.0 tag of vyos-1x and other packages and use 1.4.0 tag of vyos-build for the docker and such. You could. But what would that get you? 1.4.0? Absolutely not. For this reason alone you always want to stay away from the specific release number/tag. It's just misleading calling something 1.4.0 if it's not.

You will always can get is the future 1.4.x, since even the tagged VyOS packages aren't always fixed in time (often they are but some aren't), thus if you build some tag one day it will give you different result another day, since you are not tagging the source code, you are tagging the build script that sometimes has loose reference to the source code.

You should treat the version as timestamp because that's basically what it is, thus you can't wind back the time to build previous version in the future. That's just the VyOS packages, the fact that the Debian base system will be different is whole another deal because combining newer base system with older VyOS code may brake things, Debian is fairly stable with updates but it's not bulletproof and VyOS integrates/depends on a lot of things.

Why would you want to build specific tag? If VyOS doesn't make mistakes then whatever future version you are building is better version of 1.4.0 anyway.

There is case where sometimes VyOS pushes bad commits and breaks the stable branch but that's something they trying to avoid and it's fairly rare. I do think the fixes by the loose commits outweight the bad ones and it's not like you have choice. The bad commits most of the time break the build so most likely you won't get any ISO, the chance of bad ISO is fairly low.

The tags on vyos-1x, vyos-build and others are the for visual reason, that's the version the resulting VyOS .deb package will have. I don't think it has any deeper meaning.

[GurliGebis]

Okay 🙂 Yep, I was thinking about the broken package a few days ago. And like, if we build in between two releases, if it will cause migration issues (Since they don't create migrations every time things change (that has causes migration issues for me multiple times when I can playing around with current))

[dd010101]

TL;DR Pinning to tags will only bypass the known very obvious issues that break the build but those aren't the issue at all, since they prevent you from creating broken ISO and issues created by this development style that aren't so easily to spot likely would get tagged and released... It's more issue of development style than anything we can workaround.

---

The case where sagitta build was broken is two fold: 1) It doesn't matter, if the build is broken, what really matter is, that the ISO is stable. Breakage of build and the need to wait two days isn't a problem, since this is known issue and the fix is in progress, there is no way how this kind of issue would have significant impact. 2) Such hard change should never happen in the first place for stable branch, such architectural changes are more suited for the upcoming release not for stable release. This style of development creates much deeper and real issues.

This happens because sagitta is no stable branch - as of now, it's basically fork of current branch with many changes still being back-ported, that's not how the usual stable branches of LTS distributions work. The Debian has feature freeze where no such changes are being made before the Debian release even happens let alone to do such changes after release... This is very reckless way of development - because any changes will inevitable create bugs and not only the bugs that break the build - that's the best case, there would be nasty bugs that will be passed into the ISO and even the Smoketest will not find them - that's the real issue,

Migrations - I hope they will not introduce backward-incompatible changes to the CLI/config of stable branch after release, that would be insane... The current branch has different rules that make the branch by definition unstable, thus you need to account for the fact that every ISO is lottery if it will work, this should never happen with sagitta, yet here we are!

Perhaps the stream-branch-thing will improve this, who knows.

---

If you wanted to anyway, how to do it?

I guess the easiest way is to do it via Jenkins job definition. Specifically there is Discover other refs that you could use and instead of branch, you can build specific tags. This means you would need to update and rebuild the job via some script each release and there would be no easy way to get in between changes. This would disable the ability of Jenkins to automatically keep the repository up to date without manual innervation - unless you would make CRON that would automatically redefined the Jenkins jobs (and trigger first build) in the background once you detect new tags...

Doing it via Jenkins is the only plug and play method. If you want to do it in the scripts - that may seems like easier - because you could do auto-discovery of latest tag - this would mean you need modify the Jenkins vyos-build pipeline library and also rewrite of some of the build scripts that don't use the central the library. This way you could implement it in way - where Jenkins fetches branch, then you can auto-discovery latest tag and checkout the tag instead and then usual build can continue.

[GurliGebis]

I see 🙂 Also more of a "if stuff keeps breaking in sagitta as well".