{"id":19299971,"url":"https://github.com/cloudogu/makefiles","last_synced_at":"2026-02-09T12:17:15.084Z","repository":{"id":32229481,"uuid":"131963399","full_name":"cloudogu/makefiles","owner":"cloudogu","description":"Makefiles for cloudogu projects","archived":false,"fork":false,"pushed_at":"2024-05-23T08:17:44.000Z","size":798,"stargazers_count":4,"open_issues_count":12,"forks_count":1,"subscribers_count":11,"default_branch":"develop","last_synced_at":"2024-05-23T08:57:15.212Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Makefile","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cloudogu.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-05-03T08:15:30.000Z","updated_at":"2024-06-22T06:46:34.137Z","dependencies_parsed_at":"2024-04-19T09:29:43.194Z","dependency_job_id":"69af03e0-cf51-431f-949e-00d9973b0c4d","html_url":"https://github.com/cloudogu/makefiles","commit_stats":null,"previous_names":[],"tags_count":89,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloudogu%2Fmakefiles","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloudogu%2Fmakefiles/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloudogu%2Fmakefiles/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloudogu%2Fmakefiles/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cloudogu","download_url":"https://codeload.github.com/cloudogu/makefiles/tar.gz/refs/heads/develop","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":240401355,"owners_count":19795535,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T23:13:18.874Z","updated_at":"2026-02-09T12:17:15.045Z","avatar_url":"https://github.com/cloudogu.png","language":"Makefile","funding_links":[],"categories":[],"sub_categories":[],"readme":"# makefiles\nMakefiles for Cloudogu projects\n\nThis repository holds makefiles for building Cloudogu tools, especially those written in Go. They were created to standardize the build and release process. You should use them for every new tool you are developing in the Cloudogu environment.\n\nPlease note that `make` only accepts `Makefile`s that are **only** indented with tabs.\n\n## Quick Example\n\n```makefile\n# Set these to the desired values\nARTIFACT_ID=\nVERSION=\n\nMAKEFILES_VERSION=8.0.0\n\n.DEFAULT_GOAL:=help\n\n# set PRE_COMPILE to define steps that shall be executed before the go build\n# PRE_COMPILE=\n\n# set GO_ENV_VARS to define go environment variables for the go build\n# GO_ENV_VARS = CGO_ENABLED=0\n\n# set PRE_UNITTESTS and POST_UNITTESTS to define steps that shall be executed before or after the unit tests\n# PRE_UNITTESTS?=\n# POST_UNITTESTS?=\n\n# set PREPARE_PACKAGE to define a target that should be executed before the package build\n# PREPARE_PACKAGE=\n\n# set ADDITIONAL_CLEAN to define a target that should be executed before the clean target, e.g.\n# ADDITIONAL_CLEAN=clean_deb\n# clean_deb:\n#     rm -rf ${DEBIAN_BUILD_DIR}\n\n# APT_REPO controls the target apt repository for deploy-debian.mk\n# -\u003e APT_REPO=ces-premium results in a deploy to the premium apt repository\n# -\u003e Everything else results in a deploy to the public repositories\nAPT_REPO?=ces\n\ninclude build/make/variables.mk\n\n# You may want to overwrite existing variables for target actions to fit into your project.\n\ninclude build/make/self-update.mk\ninclude build/make/dependencies-gomod.mk\ninclude build/make/build.mk\ninclude build/make/test-common.mk\ninclude build/make/test-integration.mk\ninclude build/make/test-unit.mk\ninclude build/make/mocks.mk\ninclude build/make/static-analysis.mk\ninclude build/make/clean.mk\n# either package-tar.mk\ninclude build/make/package-tar.mk\n# or package-debian.mk\ninclude build/make/package-debian.mk\n# deploy-debian.mk depends on package-debian.mk\ninclude build/make/deploy-debian.mk\ninclude build/make/digital-signature.mk\ninclude build/make/yarn.mk\ninclude build/make/bower.mk\n# only include this in repositories which support the automatic release process (like dogus or golang apps)\ninclude build/make/release.mk\ninclude build/make/prerelease.mk\n# either k8s-dogu.mk\ninclude build/make/k8s-dogu.mk\n# or k8s-controller.mk; only include this in k8s-controller repositories\ninclude build/make/k8s-controller.mk\ninclude build/make/bats.mk\n# trivy-scan for dogu-images\ninclude build/make/trivyscan.mk\n```\n\n## Overview over make targets\n\nStarting with makefiles v5.0.0 `make help` will produce an overview of make popular targets:\n\nExample output:\n```\nmake help\n\nUsage:\n  make \u003ctarget\u003e\n\nGeneral\n  help             Display this help.\n  info             Print build information\n\nGo mod dependency management\n  dependencies     Install dependencies using go mod\n\nCompiling go software\n  compile          Compile the go program via Docker\n  compile-ci       Compile the go program without Docker\n...\n```\n\nThe actual output depends on the makefiles that your main `Makefile` includes.\n\nYou can extend the help output to your own `Makefile` in two ways:\n- add a new help section description `A new section`:\n   - `##@ A new section`\n- add a new target description `Do something`:\n  - `do-something: ## Do something`\n\nFull example:\n```makefile\n#...\ninclude build/make/variables.mk\n\n##@ A new section\n\n.PHONE do-something:\ndo-something: $(mybinary) ## Do something\n\n#...\n```\n\n## Create a new project or update it\n\nWhen creating a new project you have to import the `Makefile` and the `build` directory (with all its contents). While doing so you need to keep the directory structure, i.e. the `Makefile` and `build` folder need to be in the project's root folder.\n\nWhen there is a new release of the Makefiles in the future, you can easily upgrade your Makefiles via setting the `MAKEFILES_VERSION` variable in the `Makefile` and executing the `update-makefiles` make target:\n\n```\nmake update-makefiles\n```\n\nPlease note that there MUST NOT be done any changes within the `${BUILD_DIR}/make/` directory. Content within this directory may be removed and added during the update of the makefiles. Usually the way how the makefiles work can be modified by these to things:\n\n1. overwriting Makefile variables\n   - usually pre- or post-target variables like `POST_UNITTESTS`\n   - often these can be overwritten with project specific make targets \n1. include only one of filial makefiles that provide the an exclusive build target defined in several files\n   - f. i. `dependencies-godep` vs `dependencies-glide`\n\nThe `build/make` folder holds all Makefiles referenced by the `Makefile` in the root folder. This main `Makefile` can be adjusted to your needs. For example, if you want to build a Go project and pack it into a .deb package you can adjust your `Makefile` in the following way:\n\n### Example: Go Build with .deb package\n```\nARTIFACT_ID=app\nVERSION=0.1.2\n\nMAKEFILES_VERSION= \n\n.DEFAULT_GOAL:=compile\n\ninclude build/make/variables.mk\ninclude build/make/info.mk\ninclude build/make/dependencies-gomod.mk\ninclude build/make/build.mk\ninclude build/make/unit-test.mk\ninclude build/make/static-analysis.mk\ninclude build/make/clean.mk\ninclude build/make/package-debian.mk\n```\n\nIf you use the `package` make target, your `Makefile` will automatically use glide for downloading dependencies, compiles and creates a .deb package including the binary afterwards.\n\n### Go Build and tar.gz package\nIf you use this kind of `Makefile`, `make package` a tar.gz-package will be created instead of a debian package (see above).\n\n```\nARTIFACT_ID=app\nVERSION=0.1.2\n\nMAKEFILES_VERSION= \n\n.DEFAULT_GOAL:=compile\n\ninclude build/make/variables.mk\ninclude build/make/info.mk\ninclude build/make/dependencies-gomod.mk\ninclude build/make/build.mk\ninclude build/make/unit-test-docker-compose.mk\ninclude build/make/static-analysis.mk\ninclude build/make/clean.mk\ninclude build/make/package-tar.mk\n```\n\n## Modules\n\n### variables.mk\n\nThis module holds generic definitions needed for all builds and should be always included.\n\n### dependencies-gomod.mk\n\nThis module holds the `dependencies` target, which is utilized by the `build` target. It uses `go mod` for fetching dependencies.\n\n### build.mk\n\nThis module holds the `build` target, which starts the build inside a Docker container (to ensure reproducible builds). It also creates a checksum of the binary.\n\nThe exact golang container that is going to be used to compile Go code can be configured by overwriting the makefile variables `GOIMAGE` and `GOTAG` in the main `Makefile`. A different Go compiler version could be achieved with a line like this:\n\n```\nGOTAG=1.15.6-buster\n```\n\nThis module also supports one optional Docker volume mount to the Golang container. The sureshot default mounts the host's `/tmp` to the container `/tmp`. A custom volume mount can be expressed by overwriting the makefile variable `CUSTOM_GO_MOUNT` in your main `Makefile` with the usual Docker volume syntax:\n\n```makefile\nCUSTOM_GO_MOUNT=-v /host/path/:/container/path\n``` \n\nWhen building on Jenkins CI, make sure to mount a `/etc/passwd` file according to the Jenkins user (this file can be easily generated). This mounting is even easier with the help of the [ces-build-lib](https://github.com/cloudogu/ces-build-lib) `mountJenkinsUser()` step, like so:\n\n```\nnew Docker(this)\n .image('golang:1.14.13')\n .mountJenkinsUser()\n .inside\n``` \n\n### unit-test.mk\n\nThis module ensures that you can start Golang unit tests via the `unit-test` target.\n\nThis target can be supplemented with pre- and post-targets by setting make targets to the corresponding variables in your `Makefile` (both are optional):\n\n```makefile\n    PRE_UNITTESTS=your-pre-target\n    POST_UNITTESTS=your-post-target\n```\n\n### mocks.mk\n\nThis module adds configuration for mockery and generates all mocks via the `make mocks` target.\n\nThe mockery version can be specified in the make file. \nDirectories can be ignored with the `MOCKERY_IGNORED` variable.\nIt can be overridden like this:\n```Makefile\noverride MOCKERY_IGNORED:=${MOCKERY_IGNORED},test\n```\n\n### test-integration.mk\n\nThis module ensures that you can start Golang tests via the `integration-test` target, including an additional environment which is started and stopped using docker-compose.\n\nIntegration tests are excluded from running with the target `unit-test` by means of a build tag. Use these build tag lines to mark your test as integration test in the very first lines of the go file. \n\n```go\n//go:build integration\n// +build integration\n\npackage yourpackagegoeshere\n```\n\nThe default build tag name is defined in the global variable `GO_BUILD_TAG_INTEGRATION_TEST?=integration`. While this should fit most projects it is possible to modify the name of the build tag. \n\n#### Pre- and Post-targets\n\nThis target can be supplemented with pre- and post-targets by setting make targets to the corresponding variables in your `Makefile` (both are optional):\n\n```makefile\nPRE_INTEGRATIONTESTS=start-local-docker-compose\nPOST_INTEGRATIONTESTS=stop-local-docker-compose\n```\n\nKeep in mind that if your test relies on the target `start-local-docker-compose` you should add several targets in order to properly start docker-compose. For example:\n\n```makefile\nPRE_INTEGRATIONTESTS=yourcooltarget start-local-docker-compose anothertarget\n```\n\n#### Splitting unit tests from integration tests \n\nThis target allows also to filter test methods by regexp. This helps to avoid running regular unit-test during the integration tests, which may reside in the same package.\n\n```makefile\nINTEGRATION_TEST_NAME_PATTERN?=.*_inttest$$\n```\nNote the double dollar sign `$$` is Makefile escape syntax for the regexp line-end delimiter `$` (other delimiters may be escaped as well).\n\nFor example, setting this variable in your `Makefile` will filter tests that end with the suffix `_inttest`, i. e. \n- `func Test_yourStructCreate_inttest(t *testing.T)` **will be** executed\n- `func Test_yourStructCreate(t *testing.T)` will **not** be executed\n- `func Test_inttest_foobar(t *testing.T)` will also **not** be executed\n\n### static-analysis.mk\n\nThis module holds the `static-analysis` target for static code analysis. It automatically determines the working environment (local or CI).\n\nStatic analysis is now powered by the official Golang containers in the very same ways as it is done in `build.mk`. Any container customizations can be applied in the same way to local static-analysis.\n\nWhen running on Jenkins CI and to avoid configuration overhead it is possible to re-use  the same Golang container (that was used to compile the code) and embedd a static analysis stage there.\n\n### clean.mk\n\nThis module holds the `clean` target to clean your workspace.\n\n### package-debian.mk\n\nThis module enables you to build a debian package from the local contents. The `package` target will compile the binary and create a .deb file which holds the contents in the `deb` folder and the binary.\nThe module also enables you to build a debian package *without compiling a binary*, using the `debian` target. This makes sense for example if the debian file should consist only of configuration files.\nThe target `lint-deb-package` will show any errors or warnings for your built debian package.\n\nInclude only one of the files: package-debian.mk OR package-tar.mk\n\n### deploy-debian.mk\n\nThis module enables you to deploy or undeploy the built deb package to/from the apt repository via the `deploy` respectively `undeploy` targets.\n\nThe variable `APT_REPO` determines, which repository should be used as a target. Currently, it supports the following values:\n- `ces-premium`: The secured repositories are used\n- any other value: The public repositories are used\n\nIf you want to use this module, you also have to include the `package-debian.mk` module!\n\n#### Package requirements\n\nYou need a `deb` directory in order to successfully create a debian package. This directory is used to incorporate existing files and directories into the debian package. The minimum requirement for a valid debian package is a `control` file which you must place in `deb/DEBIAN/control`.\n\nAs an extended example, a proper directory could look like this:\n\n```\ndeb/\n L DEBIAN/\n |  L control\n |  L postinst\n L etc/ \n    L config.file\n```\n\nFiles which reside in `DEBIAN` will be subject to be stored in the `control` part of the debian package.\nIn turn, all other files and directories will be stored in the `data` part of the debian package. \n\nPlease note when you are building a debian package that all files under `/deb/etc` will be named in a automatically generated file `conffiles`. Those files will be subject to debian's conflict management instead of overwriting crucial configuration files when said configuration files already exist (f. i. when a package is upgraded).\n\n### package-tar.mk\n\nThis module lets you use the `package` target to pack a .tar archive.\n\nInclude only one of the files: package-debian.mk OR package-tar.mk\n\n### digital-signature.mk\n\nThis module makes sure that a checksum is calculated for every file in the `target` folder and signs the checksum files.\n\n### yarn.mk\n\nThis module enables you to use yarn via the `yarn-install` target.\n\n### bower.mk\n\nThis module enables you to use bower via the `bower-install` target.\n\n### release.mk\n\nThis module holds the `dogu-release` or other binary release related targets for starting automated production releases.\nAdditionally, to the regular `dogu-release` the module contains a `dogu-cve-release`. This target checks if a simple\nbuild of a dogu eliminates critical CVEs. If this is the case, a release process will be triggered.\n\nOnly include this module in dogu or Golang repositories that support a dedicated release flow!\n\n### prerelase.mk\n\nThis module is only used during the development build within the jenkins pipeline. For every develop-build. a new Version is created.\nThe dogu will be pushed in an extra `prerelease_*` namespace.\n\nTo trigger the namespace and version change manually use `make prerelease_namespace`.\n\n### bats.mk\n\nThis module enables you to run BATS shell tests via the `unit-test-shell` target. All you need is a directory with BATS\ntests in `${yourProjectDir}/batsTests` (overrideable with the variable `TESTS_DIR`).\n\n### K8s-related makefiles\n\nThe k8s-modules support remote runtimes and container-registries.\nThe environment-variable `RUNTIME_ENV`controls which runtime-environment to use:\n  * `local`: uses the local k8s-cluster at `k3ces-local` and the container-registry of this local-cluster\n  * `remote`: uses the currently configured cluster of the kube-config and the container-registry at `registry.cloudogu.com/testing`\n\nTo manually override the kube-context the environment-variable `KUBE_CONTEXT_NAME` can be used.\n\n#### k8s.mk\n\nThis module provides generic targets for developing K8s Cloudogu EcoSystem\n\n- `image-import` - imports the currently available image into the cluster-local registry.\n- `docker-dev-tag` - tags a Docker image for local K8s-CES deployment.\n- `docker-build` - builds the docker image of the K8s app.\n- `k8s-generate` - generates one concatenated resource YAML\n- `k8s-apply` - applies all generated K8s resources to the current cluster and namespace\n- check single or all of these variables:\n   - `check-all-vars`\n   - `check-k8s-namespace-env-var`\n   - `check-k8s-image-env-var`\n   - `check-k8s-artifact-id`\n   - `check-etc-hosts`\n   - `check-insecure-cluster-registry`\n\n#### k8s-component.mk\n\nThis module provides targets for developing K8s Cloudogu EcoSystem components (including controllers)\n- General helm targets\n  - `helm-init-chart` - Creates a Chart.yaml-template with zero values\n- Helm developing targets\n   - `helm-generate` - Generates the final helm chart with dev-urls\n   - `helm-apply` - Generates and installs the helm chart\n   - `helm-delete` - Uninstalls the current helm chart\n   - `helm-reinstall` - Uninstalls the current helm chart and re-installs it\n   - `helm-chart-import` - Imports the currently available chart into the cluster-local registry\n- Release targets\n  - `helm-package` - Generates and packages the helm chart with release urls.\n  - `helm-generate-release` - Generates the final helm chart with release urls.\n- Component-oriented targets\n   - `component-generate` - Generate the component YAML resource\n   - `component-apply` - Applies the component yaml resource to the actual defined context.\n   - `component-reinstall` - Re-installs the component yaml resource from the actual defined context.\n   - `component-delete` - Deletes the component yaml resource from the actual defined context.\n\n#### k8s-dogu.mk\n\nThis module provides targets for developing Dogus with a K8s Cloudogu EcoSystem.\n\n- `build` - Builds a new version of the dogu and deploys it into the K8s-EcoSystem.\n- `install-dogu-descriptor` - Installs a configmap with current dogu.json into the cluster.\n\n#### k8s-controller.mk\n\nThis module provides targets for K8s Cloudogu EcoSystem controllers.\n\n- `k8s-integration-test` - Run k8s integration tests.\n- `controller-release` - Interactively starts the release workflow.\n- `build: helm-apply` - Builds a new version of the dogu and deploys it into the K8s-EcoSystem.\n\n#### k8s-crd.mk\nThis module provides targets for managing K8S Custom Resource Definitions (CRDs) of CES controllers.\n\n- `crd-helm-generate` - Generate the helm chart containing the CRDs\n- `crd-helm-apply` - Generates and installs the helm chart containing the CRDs\n- `crd-helm-delete` - Uninstalls the helm chart containing the CRDs\n- `crd-helm-package` - Generates and packages the helm chart containing the CRDs\n- `crd-helm-chart-import` - Imports the currently available CRD chart into the cluster-local registry\n- `crd-component-generate` - Generate the CRD component YAML resource\n- `crd-component-apply` - Applies the CRD component yaml resource to the actual defined context.\n- `crd-component-delete` - Deletes the CRD component yaml resource from the actual defined context.\n \n### self-update.mk\nThis module provides targets that automatically update dependencies and build- and helper functions to the latest version.\n\n- `update-makefiles` - get the configured version of all make targets and build files\n- `update-build-libs` - patches the Jenkinsfile and adds the latest versions of the build libs to the pipeline header.\n- `set-dogu-version` - set the version number in dogus.json, pom.xml, Dockerfile, Makefile without creating a new release\n\n### trivyscan.mk\nThis module provides a target for scanning dogu images with trivy\n\n- `trivyscan` - Use trivy to scan image tagged with the version within the dogu.json. The image needs to be build first. Per default it will only show CRITICAL CVEs.\n\nUsage:\n`make trivyscan` or `make trivyscan SEVERITY='HIGH,CRITICAL'`\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcloudogu%2Fmakefiles","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcloudogu%2Fmakefiles","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcloudogu%2Fmakefiles/lists"}