notsatan / go-template Goto Github PK

Projects generated using go-template dump stderr messages in a text file in the /tmp directory. The reasoning behind this was that stderr output distracts users when everything is working, and with this setup, if there's a crash users can head over to the file in the /tmp directory to take a look at the logs.

But, there can be several scenarios where running Makefile commands might result in messages being printed to stderr — even if there are no failures — for example, warning messages. In such cases, users might not even be aware of the warning messages unless they keep checking the log file in /tmp (which is something that I doubt most people do).

Projects generated using go-template allow for a local tmp directory inside the project directory.

Though, at the moment, this tmp directory is not being automatically created through the post-gen hook (maybe this needs to change as well).

This issue simply suggests altering the existing behaviour to dump stderr logs generated by Makefile commands in the project local tmp directory instead of the global /tmp directory.

With #27, the Makefile allows creating two types of docker images;

• Images in debug mode use golang as the base image for the final build - meaning that debug builds have go installed in them, and can be shell-ed into. This comes at the cost of relatively large build sizes
• Images in production mode use scratch as the final base image - resulting in extremely small build sizes, at the cost of an almost empty container that won't be helpful for debugging!

Currently, there is no way for applications to "detect" if they are being run in debug mode or production mode!

Implementing a way to detect this would lead to nifty use-cases such as applications switching their logger to debug level when the application is being run in the debug container and more

For a new project generated using go-template, release-drafter does not work out-of-the-box as expected. When a new pull request is merged, release-drafter runs as an action, but fails to update the draft release with information related to the merged pull request.

This bug might be related to the fact that a specific version of release-drafter is pinned in workflow currently

The README.md file generated in the docker/ directory specifies a command that is incompatible with the generated Dockerfile. Specifically:

Since the final image created by the Dockerfile is a scratch image, there is no shell to attach to:

$ docker run -it --rm -v $(pwd):/workspace go-template-test bash
docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "bash": executable file not found in $PATH: unknown.

The suggested command should probably be something like this:

$ docker run --rm go-template-test
Running project: go-template-test

It might also be worthwhile to add support to the Makefile for generating a "production" image that is based on scratch, and a "development" or "debug" image that is based on an alpine or bash image. For instance:
make docker-gen DEBUG=true

As of now, projects generated using go-template will have workflows that are designed to run automatically on certain triggers (pushes/merges, etc). At the same time, Github also allows specifying a dispatch trigger that can be used to manually trigger a pipeline from the UI — meaning, no need to push empty/pseudo-empty commits just to trigger a pipeline!

Allows users to manually triggering pipeline would be a powerful feature, and allows for a lot of possibilities.

Hi!

Thanks for your repo!
The first time I try it failed. Don't know why

╰─$ cookiecutter gh:notsatan/go-template
You've downloaded /Users/mac/.cookiecutters/go-template before. Is it okay to delete and re-download it? [y/n] (y):
  [1/12] project_name (example-project): sqlite_saver_go
  [2/12] project_description (SqliteSaverGo is a Go application created using https://github.com/notsatan/go-template):
  [3/12] go_module_path (github.com/example/sqlite_saver_go): github.com/HaveF/sqlite_saver_go
  [4/12] license_owner (example): havef
  [5/12] base_branch (master): main
  [6/12] contact_email ():
  [7/12] github_specific_features (y):
  [8/12] private_project (n): y
  [9/12] use_codecov (y):
  [10/12] use_precommit (y):
  [11/12] Select go_version
    1 - 1.21
    2 - 1.20
    3 - 1.19
    Choose from [1/2/3] (1):
  [12/12] Select license
    1 - MIT
    2 - BSD-3
    3 - GNU GPL v3.0
    4 - Apache Software License 2.0
    Choose from [1/2/3/4] (1):


Ran into exception while running validator: `is_module_hosted_on_github`
Stacktrace: `ValueError: Attempt to enable Github-specific features when module path does not belong to github`


go-template is still under development, if you feel that the error is incorrect, you are encouraged to raise an issue at:
	https://github.com/notsatan/go-template

ERROR: Stopping generation because pre_gen_project hook script didn't exit successfully
Hook script failed (exit status: 246)

I also checked the issues, but without luck.

Thanks for your help again!

The current Dockerfile does not use layers from previous builds efficiently.

For example, since the step to copy project files i.e. COPY . . comes before installing dependencies, any changes to code would change the hash for the layer. And the next layer would go on to reinstall dependencies since the hash for the previous layer has been modified!

A non-exhaustive list of improvements that can be made to the Dockerfile;

• Dependencies should be (re)installed only if go.mod or go.sum files are modified!
• Switch to using go mod download instead of go get/install
• Remove RUN commands to create work directories - docker will create directories implicitly

Good to have;

• Reduce number of build steps

Hi,

first of all, I really like your project. I've been searching for a ready-to-use template for go projects for some time and so far have only found cookiecutter-golang but I like yours more.

However, I am a bit puzzled by the generated src folder inside the generated project. That seems to me non-idiomatic go as described here

In my case I would probably delete the src folder after the project has been created.

Can you explain your reasoning behind using such a folder? I'm just trying to understand why you think it's needed.

Ran into exception while running validator: is_module_hosted_on_github
Stacktrace: ValueError: Attempt to enable Github-specific features when module path does not belong to github

go-template is still under development, if you feel that the error is incorrect, you are encouraged to raise an issue at:
https://github.com/notsatan/go-template

ERROR: Stopping generation because pre_gen_project hook script didn't exit successfully
Hook script failed (exit status: 246)

... Add support to the Makefile for generating a "production" image that is based on scratch, and a "development" or "debug" image that is based on an alpine or bash image. For instance:

make docker-gen DEBUG=true

Originally suggested by @leviable in #23

Gentle suggestion to use main for default base_branch instead of master.

Avoiding the broader debate about the reasons for and utility of the name change, the industry is trending in the direction of using main as the default base branch, and is arguably beyond the critical mass of adoption necessary. The major players in the space (GitHub, Gitlab) and associated tooling have already or will soon be switching to main, and as a related tool go-template might be best served by adopting that change now.

Go 1.18 introduced Fuzzing as a method of testing

While there is nothing in the generated template that would interfere with Fuzzing, it would be nice to have an explicit Make flag to run fuzz tests. Can also trigger both normal and fuzz tests within the test-suite flag

This change would also require some minor documentation changes for the fuzz flag

Running linters on a project generated with go-template results in the multiple warning messages;

WARN [runner] The linter 'deadcode' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused. 
WARN [runner] The linter 'varcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused. 
WARN [runner] The linter 'ifshort' is deprecated (since v1.48.0) due to: The repository of the linter has been deprecated by the owner.  
WARN [runner] The linter 'structcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused. 
WARN [linters_context] structcheck is disabled because of generics. You can track the evolution of the generics support by following the https://github.com/golangci/golangci-lint/issues/2649.

Apparently, a handful linters have been abandoned/deprecated in sometime. The .golangci.yml generated needs to be modified to deal with these messages

Note that none of these are error messages, or will fail the linter/pipeline. Just some annoyances that need to be addressed

The Cookiecutter template generated allows choosing versions between 1.16, 1.17 and 1.18

The template needs to be updated to support the later versions of Go that have released since. Ideally, this should be as simple as modifying the user choices, provided the naming used to generate docker templates, etc holds up. Needs some minor testing before this can be confirmed

The YML for GCI linter no longer supports the local-prefixes field as mentioned in the updated linter-settings for GCI. Attempting to use the field results in a warning;

WARN [linters context] gci: `local-prefixes` is deprecated, use `sections` and `prefix(github.com/notsatan/go-template)` instead.