-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Makefile #221
Add Makefile #221
Conversation
install: | ||
@# config | ||
install -d $(DESTDIR)$(sysconfdir)/icinga-notifications | ||
install -m644 config.example.yml $(DESTDIR)$(sysconfdir)/icinga-notifications/config.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why changing this to 644
? We use 640
literally everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect the permissions to still be taken care of by the packaging as the owner has to be set there anyways (and probably isn't even known until installation time due do dynamically allocated user/group IDs). I wouldn't have given -m
at all (like I did for the install -d
above), but that would result in the file being executable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this Makefile supposed to simplify the Debian rules file? If this file doesn't take care of permissions handling, as we already do in override_dh_auto_install
, I don't see how this is supposed to make things simpler, other than to de-duplicate the go build ..
parts, for which by the way you don't use the same build flags as we do for the package builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this Makefile supposed to simplify the Debian rules file? [...] I don't see how this is supposed to make things simpler, other than to de-duplicate the
go build ..
parts
It takes care of which files to build an where to install them.
So it should be possible to remove the override_dh_auto_build
and override_dh_auto_install
targets from debian/rules
(those should call make
/make install
automatically) and then simply set the permissions in override_dh_fixperms
(I'm not sure if debian/icinga-notifications
is the correct prefix for the path there):
override_dh_fixperms:
dh_fixperms
chmod -R o= debian/icinga-notifications/etc/icinga-notifications
for which by the way you don't use the same build flags as we do for the package builds.
These can be set using an environment variable: GOFLAGS='-buildvcs=false -trimpath'
We could consider always adding -trimpath
, but I wouldn't add -buildvcs=false
to the Docker image builds as these are built from a Git checkout and thus receive the proper information that way.
@# dameon | ||
install -D build/icinga-notifications $(DESTDIR)$(sbindir)/icinga-notifications | ||
@# channel plugins | ||
install -d $(DESTDIR)$(libexecdir)/icinga-notifications/channel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name channel
does not make sense to me here, we will not have only one channel there, so I have already adapted this to channels
in the Debian rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That has already come up in #210 (comment) as well. Simply using a different path here would introduce an inconsistency with the default path used in the binary:
ChannelPluginDir string `yaml:"channel-plugin-dir" default:"/usr/libexec/icinga-notifications/channel"` |
So if that's supposed to be changed, that's something for its own PR. I don't care too much if it's singular or plural, I wouldn't say any is more or less correct than the other.
Makefile
Outdated
@# database schema | ||
install -d $(DESTDIR)$(datadir)/icinga-notifications | ||
cp -r --no-dereference -v schema $(DESTDIR)$(datadir)/icinga-notifications | ||
chmod -R u=rwX,go=rX $(DESTDIR)$(datadir)/icinga-notifications |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here as well, why do you need to grant others access to that directory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no reason why this shouldn't be world readable. These files are coming straight from the package, anyone could download them anyways. The explicit chmod
is there to ensure consistent permissions even if a more restrictive umask 077
is set during the build as cp
has no option to specify the desired permission and install
has no recursive mode.
6fc67d4
to
9478de6
Compare
It's a very basic Makefile providing just the all/test/install/clean targets intended to avoid duplication of the build and installation steps in the Dockerfile and the rpm/deb packaging repos. /usr/sbin was chosen for the installation path because that's where the Icinga DB packages place the binary. By using the Makefile, the Docker image will now also include the default config and the schema files.
This allows building packages with different values of libexecdir with the daemon binary automatically adapting the channel plugin dir to it, i.e. so there is no need to specify it in the config file. This is relevant for Suse where %{_libexecdir} expands to /usr/lib instead.
Previously, the path to the config file had to be passed on the command line. This commit adds a sensible default so that this is no longer necessary. As the mechanism for setting the channel plugin dir based on libexecdir from the Makefile is already there, the same was used for sysconfdir, even though that should always be /etc for our packaging needs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usage log
$ export DESTDIR=out prefix=/lusr sysconfdir=/aaaa
$ make
mkdir -p build
go build \
-o build/ \
-ldflags "-X 'github.com/icinga/icinga-notifications/internal.LibExecDir=/lusr/libexec' -X 'github.com/icinga/icinga-notifications/internal.SysConfDir=/aaaa'" \
./cmd/icinga-notifications
go build -o build/channel/ ./cmd/channel/...
$ make install
install -d out/aaaa/icinga-notifications
install -m644 config.example.yml out/aaaa/icinga-notifications/config.yml
install -D build/icinga-notifications out/lusr/sbin/icinga-notifications
install -d out/lusr/libexec/icinga-notifications/channel
install build/channel/* out/lusr/libexec/icinga-notifications/channel/
install -d out/lusr/share/icinga-notifications
cp -rv --no-dereference schema out/lusr/share/icinga-notifications
'schema' -> 'out/lusr/share/icinga-notifications/schema'
'schema/pgsql' -> 'out/lusr/share/icinga-notifications/schema/pgsql'
'schema/pgsql/upgrades' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades'
'schema/pgsql/upgrades/001.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/001.sql'
'schema/pgsql/upgrades/002.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/002.sql'
'schema/pgsql/upgrades/003.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/003.sql'
'schema/pgsql/upgrades/004.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/004.sql'
'schema/pgsql/upgrades/005.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/005.sql'
'schema/pgsql/upgrades/006.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/006.sql'
'schema/pgsql/upgrades/007.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/007.sql'
'schema/pgsql/upgrades/008.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/008.sql'
'schema/pgsql/upgrades/009.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/009.sql'
'schema/pgsql/upgrades/010.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/010.sql'
'schema/pgsql/upgrades/011.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/011.sql'
'schema/pgsql/upgrades/012.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/012.sql'
'schema/pgsql/upgrades/013.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/013.sql'
'schema/pgsql/upgrades/014.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/014.sql'
'schema/pgsql/upgrades/015.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/015.sql'
'schema/pgsql/upgrades/016.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/016.sql'
'schema/pgsql/upgrades/017.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/017.sql'
'schema/pgsql/upgrades/018.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/018.sql'
'schema/pgsql/upgrades/019.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/019.sql'
'schema/pgsql/upgrades/020.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/020.sql'
'schema/pgsql/upgrades/021.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/021.sql'
'schema/pgsql/upgrades/022.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/022.sql'
'schema/pgsql/upgrades/023.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/023.sql'
'schema/pgsql/upgrades/024.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/024.sql'
'schema/pgsql/upgrades/025.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/025.sql'
'schema/pgsql/upgrades/026.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/026.sql'
'schema/pgsql/upgrades/027.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/027.sql'
'schema/pgsql/upgrades/028.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/028.sql'
'schema/pgsql/upgrades/029.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/029.sql'
'schema/pgsql/upgrades/030.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/upgrades/030.sql'
'schema/pgsql/schema.sql' -> 'out/lusr/share/icinga-notifications/schema/pgsql/schema.sql'
chmod -R u=rwX,go=rX out/lusr/share/icinga-notifications/schema
$ ./out/lusr/sbin/icinga-notifications -version
Icinga Notifications version: 0.0.0-g9ad4cbc-dirty
Build information:
Go version: go1.22.3 (linux, amd64)
Git commit: 9ad4cbcc5cc4964663e573d7dedee4d57a6a059b (modified)
$ make clean
rm -rf build
It's a very basic Makefile providing just the
all
/test
/install
/clean
targets intended to avoid duplication of the build and installation steps in the Dockerfile and the rpm/deb packaging repos./usr/sbin
was chosen for the installation path because that's where the Icinga DB packages place the binary.By using the Makefile, the Docker image will now also include the default config and the schema files.
Additionally, the Makefile sets two Go variables to the values of
libexecdir
andsysconfdir
usinggo build -ldflags '-X ...'
. This allows the daemon to use these values for the channel plugin dir and the default config path (which had no default so far and is added by this PR). Adding this mechanism is necessary for building proper packages for Suse where%{_libexecdir}
expands to/usr/lib
.