Skip to content

Migrating from 0.4 to 0.5

dnspatch is v0.x: the configuration format and the plugin API may change between minor versions. This page lists what breaks in 0.5 and how to adapt.

0.5 changes which plugins the lightweight build has, and the build tags that choose them. A configuration file that worked on 0.4 works on 0.5 unchanged, as long as the build it runs on has the plugins it names. Two groups of people are affected:

  • those who use the rfc2136, yandexcloud or namecheap provider on the dnspatch image, the dnspatch_* archive or a plain go install;
  • those who build dnspatch with build tags (ping, notify_all, providers_all, retrievers_all), in a script, a Dockerfile or CI.

Everything else in 0.5 is additive.

The lightweight build no longer has three providers

rfc2136, yandexcloud and namecheap are left out of the lightweight build, because the libraries they need make the binary 0.1 to 0.7 MB larger. The lightweight build is now about 7.4 MB for amd64 instead of 8.4 MB; the full one is about 10.9 MB. A configuration that names one of them is rejected at startup and says how to get it:

instance "home": provider type "rfc2136" is not compiled into this build: rebuild with the "rfc2136" or "full" build tag, or use the -full image (see https://dnspatch.github.io/dnspatch/deployment/building/)

Switch to the full build, which has every plugin:

Where Before Now
Image krimsn/dnspatch:0.4, latest krimsn/dnspatch:0.5-full, latest-full
Archive dnspatch_* dnspatch-full_*
go install go install ...@v0.4.3 go install -tags full ...@v0.5.0

Or build a binary with just the provider you use on top of the lightweight one:

go install -tags rfc2136 github.com/dnspatch/dnspatch/cmd/dnspatch@v0.5.0

The -full image tag exists since 0.4.0, so a pinned -full tag only needs its version raised. See Installation and Image tags.

Build tags

The tags that gave a build its optional parts are replaced by one, full, and the tag of each plugin:

  • full compiles in every plugin. It wins over dnspatch_none.
  • dnspatch_none leaves out every retriever and provider, and <plugin> brings back the one with that type name, as before.
  • For a plugin that the lightweight build leaves out (the three providers above and every notifier), its tag adds it to the lightweight build: -tags "rfc2136,redis".
  • ping, notify_all, providers_all and retrievers_all are gone. A tag that no file mentions does not make go build fail, so an old command still builds, only into something other than what you meant. Check the tags of every script.
Before Now
-tags "ping,notify_all" -tags full
-tags ping no tag: ping_url is in every build
-tags notify_all -tags full, or -tags "redis,rabbitmq,mqtt" for the notifiers alone
-tags "ping,redis" -tags redis
-tags providers_all no tag for the providers of the lightweight build; -tags full adds the three that it leaves out
-tags "dnspatch_none,providers_all" -tags full, or dnspatch_none and the tag of each provider you use
-tags "dnspatch_none,retrievers_all,cloudflare" -tags "dnspatch_none,2ip,icanhazip,identme,ifconfigco,interface,ipify,cloudflare"
--build-arg TAGS=ping,notify_all --build-arg TAGS=full

The tags of the other kinds of build are not touched: dnspatch_none,ipify,cloudflare is the same smaller binary as before. The table of every plugin and its tag is in Building from source.

ping_url works in every build

The hook costs 8 KB and needs no library, so it is no longer behind a tag, and the lightweight build accepts ping_url. A configuration that worked on the full build keeps working, and one that used ping_url only needs the full build for its notifiers, if it has any. A custom build with -tags ping needs no change beyond dropping the tag. See Monitoring.

For tools and plugin authors

  • schema.json of a release lists full as a build tag of every plugin (in place of providers_all, retrievers_all and notify_all), and has a new field per plugin, in_default_build: whether a build made without tags has it. schema_version stays 1, since a reader of the old format loses nothing. The online builder reads both forms.
  • A plugin package that should be left out of the lightweight build carries the line //dnspatch:extra in its package comment. go generate reads it, and every notifier is left out without it. See Writing a plugin.
  • plugin.Known has a new field Extra, and Registry has DeclareExtra next to Declare. A program that embeds dnspatch through app needs no change.