Tags are not built by default (because otherwise you could have a build storm when checking out a repository) and worse, the order tags will be built in is unpredictable... and you might have a Jenkinsfile that deploys to production when a tag is built.

There is an extension point in branch-api called BranchBuildStrategy which - if implemented - will allow deciding whether to build tags.

See https://github.com/jenkinsci/github-branch-source-plugin/pull/158#issuecomment-332773194 for starting point on how to create such an extension plugin... I believe there is some work on one at https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin

Functioning as designed

you could have a build storm when checking out a repository

I don't get this. What do you mean? I'm quite surprised by this design decision, other CI system build tags automatically and I never had any problems with it.

Checking out the repository where could have a build storm?

You could have a build storm if you have 200 tags, they all get discovered and queued for building... and your tags are set up to deploy to production because they are tags... and jenkins does not guarantee the order in which the tags will be discovered or actually executed... so production is constantly cycling different versions.

In any case, if you want to build tags just install the Basic Branch Build Strategies plugin and configure it: https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/docs/user.adoc#tags

You could have a build storm if you have 200 tags, they all get discovered and queued for building... and your tags are set up to deploy to production because they are tags... and jenkins does not guarantee the order in which the tags will be discovered or actually executed... so production is constantly cycling different versions.

That is stupid. Why the person who is responsible for configuration cannot decide about this? There could be simple checkbox (unchecked by default) with message: "Trigger build as well" and additionally funcionallity from 'Basic Branch Build Stratiegies' could be copy over. I'm talking about tags being older then X days and so on.

sobi3ch So first off we have the Jenkins Queue.

The queue does not know about multibranch as belonging to a single "project" so instead it sees them all as different jobs. The queue is designed to care about the order within a job but not the order between jobs.

Each tag gets its own job, thus the tag v1 could be built after the tag v5 even if v1 was put in the queue before v5... there is nothing to do with multibranch, you can get the same effect with regular freestyle jobs

Next, the tag discovery is not in a deterministic order from git.

Simple tags do not even have a creation timestamp in the git data model

Annotated tags do have a creation timestamp, but that does not reflect the push time

So we have no way to reconstruct the order of simple tags, and we only have a way to reconstruct the creation order of annotated tags... that is not the actual release (i.e. push to canonical repo) order

Ok, so you might say "well sort the tags"... hmmm except sorting version numbers is a hard problem... does where does RC go w.r.t. alpha, beta, milestone, etc. There are some widely held conventions... but nothing that is a hard and fast rule.

Finally, if you really want them built on discovery, it's an extension point you can write a plugin that does exactly that and install it... then just configure that option in the build strategies... I just choose not to enable users to easily shoot themselves in the foot... I do not prevent the foot shootings

Seriously, all you need to do is copy one class and change the logic for automatic build to return head instanceof TagSCMHead; (cf https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/src/main/java/jenkins/branch/buildstrategies/basic/BranchBuildStrategyImpl.java#L55-L64) and then you can shoot your own foot off.

I will not be adding such an implementation into any plugin I maintain (because I do not want to hear the howls of users on the receiving end of self-foot-shootings) but feel free to roll your own and release it as a plugin to the community (as long as you support the users with the shot feet)