schwarzit/go-template

go/template is a tool for jumpstarting production-ready Golang projects quickly.

go-template's Issues

Apache 2.0 license file generation should NOT replace the placeholders

What happened?

After generating a project using the Apache 2.0 license, I've discovered that the current year and my name were replaced with the placeholders that should be there in the license file.

These placeholders should not be replaced. See e.g. the Google guidelines https://opensource.google/documentation/reference/releasing/preparing#license-file:

For the Apache License, simply copy the official 2.0 license into your LICENSE file verbatim (do not edit the Copyright section in the template, only when you use that template in the header of your source code files.) [...]

Why shouldn't I edit the template in the Apache License? The "LICENSE" file is supposed to be our inclusion of an exact copy of https://www.apache.org/licenses/LICENSE-2.0.txt as required by section 4(a) of the Apache 2 license, so we shouldn't modify it in any way, such as by adding our copyright notice. Also, the Appendix (lines 179-202) represents a notice to third-parties informing them of how they should apply the Apache 2 license to their own works, so inserting our copyright notice in place of the template text renders those instructions incorrect. Many projects insert copyright notices into their LICENSE file at line 190 because this is a common and understandable misinterpretation of the license's instructions. We should attempt to fix this wherever we find it, particularly for first-party projects.

How can we reproduce this?

Run gt new and select the Apache 2.0 license. Inspect the generated LICENSE file, in line 190 and see that the placeholders of the original license have been replaced.

gt version

0.3.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

The main repo does it right (

go-template/LICENSE

Line 190 in d97730d

Copyright [yyyy] [name of copyright owner]

), just the generated files are wrong :)

golint is deprecated

The golint for golangci is deprecated. Maybe replace it with revive?

WARN [runner] The linter 'golint' is deprecated (since v1.41.0) due to: The repository of the linter has been archived by the owner.  Replaced by revive.

revive repo -> https://github.com/mgechev/revive

Renovate does not update nix lockfile

What happened?

Renovate updates update the go.sum file but not the nix lockfile which breaks the nix derivation.
Probably an additional renovate step is required to fix that.

How can we reproduce this?

gt version

-

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Add pipeline step to validate the `go generate` was run

It is mandatory to run go generate whenever new files are added to make sure that all dotfiles are included in the embedded template.
Therefore we need a validation step in the pipeline that the generated file is up to date.

`buf.work.yaml` is generated even though grpc is `false`

What happened?

I created a new project with gt new and disabled the grpc extension but I still got the buf.work.yaml file.

How can we reproduce this?

run gt new and set false for the grpc extension.

gt version

0.4.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Replace Makefile with earthly

Is your feature request related to a problem? Please describe.

Makefiles are fast hard to read & to maintain. It would be nice to have a more elgant alternative like earthly.

Describe the solution you'd like

Replace current Makefile with an Earthly file. Earthly could also be split up into multiple files & folders. So this could also help to make go-template fit for more options, since not everything needs to be going into one file.
Also with earthly, supporting multiple CI provider would be much easier.

Describe alternatives you've considered

Keep the Makefile 😁

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Check for protobuf breaking changes only against master branch

What happened?

When creating a project with gRPC support, the command make protobreaking checks only against master branch.
Better would be checking against the current main branch and not hard-coded a specific branch.

How can we reproduce this?

Create a new project with gRPC support and run make protobreaking where no master branch exists.

gt version

0.4.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

goreleaser version conflicts with templates

What happened?

The release pipeline run https://github.com/SchwarzIT/go-template/actions/runs/3394226442 fails because of some templating issue.

How can we reproduce this?

See pipeline

gt version

-

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Set ZAP loglevel via environment var

Is your feature request related to a problem? Please describe.

It's useful for 12factor apps.

Describe the solution you'd like

Set Zap logging level through an environment var.
Example for debug: LOG_LEVEL=debug

Describe alternatives you've considered

...

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Release is not triggered by tag_release pipeline

What happened?

tag_release pipeline creates a tag trough the github rest api which apparently does not trigger the release workflow (which triggers on: push: tag: *).

How can we reproduce this?

Try to use the release flow described in the release docs using the hack/release.sh script.

gt version

-

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Add documentation for dependency on git and go

It should be documented that gt requires git and go to be installed and available on PATH.
Otherwise the new command fails.

Add protobuf linting into ci

Is your feature request related to a problem? Please describe.

Currently, in the CI the protobuf files will not be linted.

Describe the solution you'd like

Nice would be to add them into the make ci command and also make sure that this will be integrated into all generated CI's provider.
Also add the linting to the pre-commit.

Describe alternatives you've considered

Some way that the protobuf files will be linted.

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Invalid Protobuffer files

What happened?

When creating a new project with a - in the name like test-gt and enable gRPC. The generated protobuffer package name and the example service will contain also the - but this is invalid for protobuffer.

How can we reproduce this?

Create a new project which contains a - in the name like test-gt.

gt version

0.4.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Update docker image to latest go version

The Docker image is currently using a fixed go v1.20 for the builds.

go-template/_template/Dockerfile

Line 4 in 1152abd

FROM golang:1.20@sha256:098d628490c97d4419ed44a23d893f37b764f3bea06e0827183e8af4120e19be AS base

We should probably update that to use golang:alpine without a fixed hash, to always build with the latest Go version. This would bring important security updates, and we wouldn't need to change the version on every new Go release.

blocked by #313

`appName` that contains a `-` leads to an error in proto file

What happened?

❯ make generate           
PATH=/private/tmp/awesome-project/bin:$PATH buf generate
api/proto/awesome-project/v1/awesome-project.proto:3:17:syntax error: unexpected '-', expecting ';'
make: *** [generate] Error 100

How can we reproduce this?

Create a new project using the following file (gt new -c values.yaml):

# values.yaml
base:
  projectName: Testing Project
  projectSlug: testing-project
  projectDescription: Some project used for testing
  appName: testing-project
  moduleName: github.com/fake/testing
  golangciVersion: 1.42.1
extensions:
  grpc:
    base: true

Then run make generate.

gt version

0.3.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

Probably the issue is the newly added support for dashes in appNames which are not allowed in protobuf.

feat: add goreleaser for gt cli

Hi everyone,

I would like to contribute the goreleaser support for gt.

Discussion under -> #43

Add documentation for automaxprocs

There is a missing documentation about automaxprocs.

How does it works and what does it?

Split Makefiles across multiple usecases with includes in main Makefile

Not all Makefile commands are suitable for all projects. Also the current Makefile is not really suitable for extensions since it's already packed with targets and tends to get confusing.
To improve readability the Makefile should be moved into mutliple default Makefile targetted at specific usecases and then be included in a main Makefile.
In this Makefile it's then also possible to add targets specific to the project.

Upload findings to GitHub Advanced Security Dashboard

Enable in semgrep.yml Upload findings to GitHub Advanced Security Dashboard.

Migrate to slog

We currently use zap in internal/log.
Since Go v1.21 slog was introduced to the Go stdlib, and it aims to replace all external logging libraries. We should adapt the template and remove the internal/log package, as the users do not need it anymore (and should prefer to use slog).

Up for discussion

We can discuss if we want to initialize slog in the template, or if we want to let the user do that.

`grpc.base=false` does not delete grpc files if `opensource.license=9`

When running gt new and using the defaults and setting grpc.base to false the files are deleted properly.
When doing the same but setting opensource.license to 9 (no license) the files are still present after generating.

Allow numbers, underscores and dashes in `appName`

Currently only lowercase letters are allowed in the appName during initialization.
When looking at a lot of executables out there (e.g. k3s or semgrep-agent) this might be a bit too aggressively validated.
Therefore we should probably also allow underscores, dashes and numbers in the appName.

Outdated buf integration.

Is your feature request related to a problem? Please describe.

Buf is already part of the template to support gRPC projects. Sadly it's outdated and should support the new v1 version and probably also remote plugins.

Describe the solution you'd like

An update of the existing buf support.

Describe alternatives you've considered

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Linting Error in Main.go

What happened?

When generating a new project. The main file has a linting error (shadow import) for the logger.

How can we reproduce this?

Generate a new project.

gt version

0.4.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

Add in CI a linter for the generated project.

Improve Dockerfile

Currently the Dockerfile is based on a local binary that is already built which is then just copied into the Container Image.
For a lot of usecases (e.g. pipelines to allow remote caches, devspace setup) the experience can be improved by building the app directly in the Dockerfile instead of building it upfront.
This is why build targets should be added to the Dockerfile.

Calculate release version automatically with `svu`

Is your feature request related to a problem? Please describe.

Currently it's required to set the new version tag manually when running make release.

Describe the solution you'd like

Since we're using semantic commits we can instead use caarlos0/svu to calculate the new release version automatically.

Describe alternatives you've considered

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Codeowners file will be generated for no OpenSource projects

What happened?

When creating a new no OpenSource project, a codeowner files will be generated.

How can we reproduce this?

Create a new project and select for License No OpenSource

gt version

0.4.1

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Enable Github Discussions

Github Discussions should be enabled on the repo to allow anyone to ask questions and raise discussions without instantly opening an issue.

Improve documentation on folder structure

Documentation on the following topics/ questions should be improved:

• why was this structure chosen
• how to use the folder structure (what should be put where)
• disclaimer that the structure should not be enforced if it doesn't fit the project but can be used as default
• where do the other config files come from (Makefile, .golangci.yml, etc.)

Automate demo gif

Is your feature request related to a problem? Please describe.

The asciinema preview is often outdated and also requires a webplayer to run.

Describe the solution you'd like

It would nice to create the demo automatically and include it in the README as a svg animation to autoplay as soon as a user opens the repo.

Describe alternatives you've considered

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

https://github.com/brumhard/krewfile already contains a script to automatically create the animation.
One thing that is missing is how to feed stdin to the executed command.

Dependency Dashboard

This issue provides visibility into Renovate updates and their statuses. Learn more

This repository currently has no open or pending branches.

---

• Check this box to trigger a request for Renovate to run again on this repository

Dotfiles and directories that only contain dotfiles are not included in the resulting directory

Due to golang/go#43854 the go:embed directive does not include dotfiles and empty directories (or dirs that only contain dotfiles such as .gitkeep). Because of this the created project directory when running gt new does not contain the all those files.

Use new --link option in Dockerfile

Is your feature request related to a problem? Please describe.

Not related to a problem, I'm suggesting an improvement to the Dockerfile

Describe the solution you'd like

Add the --link option to the COPY from the build stage into the final distroless stage.

COPY --from=build --link /app/main /

This will improve cache efficiency and allow for image rebasing (e.g. when there's a new distroless image release, Docker can just rebase the previous build onto the new image)

However, this isn't supported on older Docker versions without support for Dockerfile 1.4

Describe alternatives you've considered

Alternatives:

• Put the --link flag behind an option
• Leave it as-is

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

If this feature request is accepted, I can work on this.

https://www.docker.com/blog/image-rebase-and-improved-remote-cache-support-in-new-buildkit/
https://github.com/moby/buildkit/blob/dockerfile/1.4.0/frontend/dockerfile/docs/syntax.md#linked-copies-copy---link-add---link

Improve goreleaser config

We currently only have a minimal goreleaser setup. This could be enriched with the following:

• better changelogs with github and semantic commits
• release footer with gt new
• universal_binaries for mac OS
• cosign (#69)
• brew tap
• scoop
• Docker images
• fury.io to publish linux packages

Add Docker-Compose Options

Is your feature request related to a problem? Please describe.

No, just an enhancement.

Describe the solution you'd like

Add an Option to create a local (dev) docker-compose setup with fully working containers like:

• Postgres
• S3
• Redis
• etc.

This could help to create working dev environment.

Describe alternatives you've considered

Just keep the plain Dockerfile.

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

go/template v2

go/template v2

So after around 1,5 years of using go/template we see some room for improvement in several parts.

context

• the project started out as a opinionated internal template
• after open source we tried to transition to a less opinionated and more generic template and therefore minimized the folder structure etc.

Anyways, go-template currently only supports one embedded template as the source of truth and we found out that this can't support all the different requirements that arise in different projects, e.g. switching out the build tool etc or supporting a new technology.
Also there has always been this conflict between providing too much and needing to delete a lot or too few to really be relevant.

stuff that the new template engine should support

• every feature of the old engine
• earthly -> one file additionally replacing e.g. make
• shared files like gitignores
• specific library quickstarts e.g. ent
• technology specifics like gRPC
• prometheus, instrumentation
• database implementation postgres
• dummy business logic
• CLI vs server/backend
• completely different project architecture like pulumi provider template

envisioned/possible solutions

• modular system (maybe gRPC plugin based like terraform/pulumi)
• modules provide specific functionality, the exact scope will have to be defined
• modules/plugins can be opinionated, the go-template itself should be fairly generic
• it might be necessary that plugins have dependencies to other modules, and also to edit existing files
• users can define what modules they want to use
• some modules will be embedded/vendored with go-template but the system allows others to write their own modules

golangci is broken from the makefile

Since yesterday the golangci installation from the Makefile is broken.

$ curl -sfL https://install.goreleaser.com/github.com/golangci/golangci-lint.sh | bash -s -- -b bin v1.42.1
> golangci/golangci-lint info checking GitHub for tag 'v1.42.1'
> golangci/golangci-lint info found version: 1.42.1 for v1.42.1/linux/amd64
> golangci/golangci-lint info installed bin/golangci-lint
> golangci/golangci-lint err this script is deprecated, please do not use it anymore. check https://github.com/goreleaser/godownloader/issues/207
> go mod download
> bin/golangci-lint run
> level=error msg="Running error: context loading failed: no go files to analyze"

There a several other ways to install golangci → https://golangci-lint.run/usage/install/
Which version do we want to use?

Ignore CI for release PRs

Is your feature request related to a problem? Please describe.

Release PRs just edit the version.txt file but trigger the whole CI workflow which is just a waste of resources.

Describe the solution you'd like

Ignore updates to the version file in the CI.

Describe alternatives you've considered

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Add pipeline template for azure devops

To improve CICD integration of go/template we should add some pipeline templates for a basic linting setup running the make ci target.
This issue is to discuss the CICD integration for azure devops specifically.

Add pipeline template for github

To improve CICD integration of go/template we should add some pipeline templates for a basic linting setup running the make ci target.
This issue is to discuss the CICD integration for github specifically.

Add goreleaser support to the template

goreleaser is a commonly used tool in the Go ecosystem to build binaries for several platforms, create a GitHub release and then for example push a Homebrew formula to a tap repository (as well as an expanding list of other targets).
It would be great to also add it as an extension to the template.

Update docs

Docs are a bit outdated currently.
Things that should be added/updated:

• how to validate build artifacts with cosign
• PRs are now squashed and no DCO check is done anymore

Remove go matrix from CI

Is your feature request related to a problem? Please describe.

Testing multiple go versions is not required for the tests.
It creates manual effort at times since required checks from old PRs are outdated after go version updates.

Describe the solution you'd like

Just test one go version.

Describe alternatives you've considered

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

githook pre-push is not executable by default

What happened?

When creating a new project. The githook pre-push is no more executable.

How can we reproduce this?

Create a new project with gt and make all && git push.

gt version

0.4.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

Please add a test in the CI for that.

Proposal for CI Simplification

Proposal for CI Simplification

Our current setup involves using multiple Continuous Integration (CI) tools, which is rather extensive for a project of our scale, particularly for a CLI tool. This proposal suggests streamlining our CI processes by consolidating tools and adopting simpler, more integrated solutions.

Suggested Changes

1. Transition from Renovate to Dependabot (DONE)

   • Rationale: Dependabot is integrated into GitHub, offering a more streamlined and user-friendly interface. Its simplicity reduces the likelihood of errors and should adequately meet our project's requirements.
   • Benefits: Dependabot not only manages dependencies but also highlights security vulnerabilities, exclusively to maintainers, adding an extra layer of security.

2. Remove semgrep (DONE)

   • Issue: The current semgrep workflow is outdated and has been causing obstructions in our PR process.
   • Alternative: Rely on Dependabot for dependency analysis, which covers similar ground and provides additional security insights.

3. Adopt a Standard GoReleaser Configuration

   • Current Situation: Our custom GoReleaser configuration, while functional, diverges from the open-source community's norms.
   • Proposal: Align with the default GoReleaser configuration, recognized and widely used within the community. This compatibility enhances our tool's interoperability with various installers and systems.
   • Release Packaging: Modify the packaging of release binaries to include .tar.gz files for macOS/Linux and .zip files for Windows. Incorporating the README.md and LICENSE files into these archives will provide users with essential information in a convenient format.

These changes aim to simplify our CI setup, improve efficiency, and align our processes with community standards, thereby enhancing our project's maintainability and accessibility.

Improve pre-push check

To make sure that all the code that is uploaded to the remote repo is in a nice format and optimized there is currently a linting step as pre-push step.
To further improve that it could be beneficial to also add go fmt and go mod tidy to pre push to make sure the code is well formatted and all the dependencies are tidied up.
Also we could think of removing the filter to only run these checks if go files are commited, since this could lead to false negatives if only the linting config is changed but no go files. Also the performance impact isn't too bad.

Checkout ORT vs syft for generating SBOM

Is your feature request related to a problem? Please describe.

No known problem.

Describe the solution you'd like

Currently this project auto generated SBOM with syft. After attemting the SBOM Devroom on the fosdem I'm currious if ORT will be generating a better SBOM than syft.
Ort claims, that it will include not just software dependencies from the package manager, it will also include warpped libs like from C++. Also, is has an Open Source Policy Checker included.
If this works as promised, we could run ORT on each PR for OpenSource licencing check and generate the SBOM with it.

Describe alternatives you've considered

Keep using syft

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Add dockerfile linting into ci

Is your feature request related to a problem? Please describe.

Currently, in the CI the Dockerfile file will not be linted.

Describe the solution you'd like

Nice would be to add them into the make CI command and also make sure that this will be integrated into all generated CI's provider.

Describe alternatives you've considered

Some way that the Dockerfile file will be linted.

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Add actual docs on all the available options

Currently the README only points to the options.go file where all the options are defined.
Unfortunately it requires some effort to understand how the options are defined and how the whole definition works in the file.
To improve the user experience some docs should be added on the available options. This could be as Markdown or some yaml definition or anything human readable.
It could also be autogenerated maybe from the options.go definitions.

go-template generates all files with executable permissions

What happened?

If you run gt new and generate a new folder (selected options do not matter) all the files will have the executable bit set.

How can we reproduce this?

Run gt new and take a look at the generated files.

gt version

0.3.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response