diff --git a/.golangci.yml b/.golangci.yml index 59cbe8f..890c9a0 100644 --- a/.golangci.yml +++ b/.golangci.yml @@ -30,7 +30,7 @@ linters-settings: goimports: # Put imports beginning with prefix after 3rd-party packages; # it's a comma-separated list of prefixes. - local-prefixes: github.com/nobl9/your-module-name + local-prefixes: github.com/nobl9/govy govet: # False positives and reporting on error shadowing (which is intended). # Quoting Robi Pike: diff --git a/Makefile b/Makefile index b102c13..860fc87 100644 --- a/Makefile +++ b/Makefile @@ -2,7 +2,7 @@ MAKEFLAGS += --silent --no-print-directory BIN_DIR := ./bin -APP_NAME := your-module-name +APP_NAME := govy LDFLAGS += -s -w # renovate datasource=github-releases depName=securego/gosec @@ -35,7 +35,7 @@ define _print_check_step endef .PHONY: build -## Build your-module-name binary. +## Build govy binary. build: go build -ldflags="$(LDFLAGS)" -o $(BIN_DIR)/$(APP_NAME) ./cmd @@ -117,7 +117,7 @@ format/go: echo "Formatting Go files..." $(call _ensure_installed,binary,goimports) go fmt ./... - $(BIN_DIR)/goimports -local=github.com/nobl9/your-module-name -w . + $(BIN_DIR)/goimports -local=github.com/nobl9/govy -w . ## Format cspell config file. format/cspell: diff --git a/README.md b/README.md index ff8abec..3757e41 100644 --- a/README.md +++ b/README.md @@ -1,113 +1,3 @@ -# go-repo-template +# govy -Repository [template](https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-repository-from-a-template) -for new Go projects. - -## Bootstrap - -Click `Use this template` button: -![image](https://github.com/nobl9/go-repo-template/assets/48822818/a5edc131-00c8-46f5-8ae6-1b593cbb4714) - -After you're done, you can run the following command to bootstrap the project -and make it ready to run: - -```shell -export MODULE_NAME= # Example: replace with "sloctl". -grep -rl your-module-name | xargs sed -i "s/your-module-name/$MODULE_NAME/g" -rm -rf bootstrap -rm gitsync.json -``` - -In order for some automations to work, like -[Release Drafter](https://github.com/release-drafter/release-drafter), -we need a predefined set of labels. -If you create a new repository from this template, the labels will be -automatically transferred for you. -However, if you want to use these automations in an existing repository, -you'll need to create these labels. -We've provided a convenience script for that, located [here](./bootstrap/add-labels.sh). -Run the following: - -```shell -./bootstrap/add-labels.sh -``` - -If you wish to update existing labels, add `--force` to the `gh label create` -invocation in the script. - -## Project structure - -The existing folders such as `cmd`, `pkg` and `internal` serve as examples on -how to structure your project. -You should remove them and change their contents to your liking, but adhere to -the structure defined -in [golang standards](https://github.com/golang-standards/project-layout). - -## Makefile - -Makefile is used as the utility -You can quickly inspect the targets of Makefile by running: - -```shell -make help -``` - -When writing new targets, make sure you document them with double `#` character -and place the comment directly above the target, like so: - -```makefile -## Document me! -new-target: - echo "Hello" -``` - -Want to include PlantUML diagrams in your project? -You can add these targets to Makefile: - -```makefile -PLANTUML_JAR_URL := https://sourceforge.net/projects/plantuml/files/plantuml.jar/download -PLANTUML_JAR := $(BIN_DIR)/plantuml.jar -DIAGRAMS_PATH ?= . - -## Generate PNG diagrams from PlantUML files. -generate/plantuml: $(PLANTUML_JAR) - for path in $$(find $(DIAGRAMS_PATH) -name "*.puml" -type f); do \ - echo "Generating PNG file(s) for $$path"; \ - java -jar $(PLANTUML_JAR) -tpng $$path; \ - done - -# If the plantuml.jar file isn't already present, download it. -$(PLANTUML_JAR): - echo "Downloading PlantUML JAR..." - curl -sSfL $(PLANTUML_JAR_URL) -o $(PLANTUML_JAR) -``` - -## Releasing - -If you wish to ship binaries for your project, we recommend using [Goreleaser](https://goreleaser.com/). -Sloctl repository has some good examples on how to define Goreleaser -[config file](https://github.com/nobl9/sloctl/blob/main/.goreleaser.yml) and also, -how to use the tool in a [GitHub action](https://github.com/nobl9/sloctl/blob/main/.github/workflows/release.yml). - -Sloctl also has examples of publishing Docker images to DockerHub. - -## Gitsync - -This repository is also used as a staple/root for other repositories to follow. -This means things like linter configs or CI/CD workflows in these repositories -are supposed to be kept in sync with this repository (with some variations). - -This is achieved with a tool called [gitsync](https://github.com/nieomylnieja/gitsync). -Configuration file for the tool is [gitsync.json](./gitsync.json). - -In order to see the diff between managed repositories run: - -```shell -gitsync -c gitsync.json diff -``` - -In order to sync the changes for managed repositores run: - -```shell -gitsync -c gitsync.json sync -``` +TODO diff --git a/bootstrap/add-labels.sh b/bootstrap/add-labels.sh deleted file mode 100755 index 716cefc..0000000 --- a/bootstrap/add-labels.sh +++ /dev/null @@ -1,23 +0,0 @@ -#!/usr/bin/env bash - -if [ "$#" -ne 1 ] || [ -z "$1" ]; then - # Display an error message and exit - echo "Usage: $0 " - exit 1 -fi - -REPO="$1" - -i=0 -while IFS= read -r line; do - ((i++)) - if [ "$i" -eq 1 ]; then - continue - fi - IFS=',' read -ra values <<<"$line" - name="${values[0]}" - description="${values[1]}" - color="${values[2]}" - echo "Creating '$name' label..." - gh label --repo nobl9/"$REPO" create "$name" --description "$description" --color "$color" -done <./bootstrap/labels.csv diff --git a/bootstrap/labels.csv b/bootstrap/labels.csv deleted file mode 100644 index 05056b3..0000000 --- a/bootstrap/labels.csv +++ /dev/null @@ -1,13 +0,0 @@ -name,description,color -security,Pull requests that address a security vulnerability,#ee0701 -infrastructure,Changes to infrastructure and CI,#2D65FE -documentation,Improvements or additions to documentation,#000000 -go,Pull requests that update Go code,#16e2e2 -javascript,Pull requests that update Javascript code,#F9D0C4 -python,Pull requests that update Python code,#0E8A16 -sh,Pull requests that update shell scripts,#7B8EE1 -chore,Routine or minor duty task,#5B5A85 -breaking-change,Any kind of non-backwards compatible change,#ee0701 -major,Large and incompatible API changes,#A22BD2 -minor,New functionality with at most minor breaking changes,#A22BD2 -patch,Bug fixes and security updates,#A22BD2 diff --git a/cmd/main.go b/cmd/main.go deleted file mode 100644 index 8576938..0000000 --- a/cmd/main.go +++ /dev/null @@ -1,29 +0,0 @@ -// Package main holds executable functions for this project. -// -// If you have more than one executable, a directory name for each application should match -// the name of the executable you want to have (e.g., /cmd/app). -// -// Don't put a lot of code in the application directory. -// If you think the code can be imported and used in other projects, then it should live in -// the /pkg directory. -// If the code is not reusable or if you don't want others to reuse it, put that code in the -// /internal directory. -// You'll be surprised what others will do, so be explicit about your intentions! -// -// It's common to have a small main function that imports and invokes the code from the /internal -// and /pkg directories and nothing else. -// -// Source: https://github.com/golang-standards/project-layout#cmd -package main - -import ( - "fmt" - - "github.com/nobl9/your-module-name/internal" - "github.com/nobl9/your-module-name/pkg" -) - -// main is the entry point for your module's executable. -func main() { - fmt.Println(internal.GetHello(), pkg.GetWorld()) -} diff --git a/gitsync.json b/gitsync.json deleted file mode 100644 index 3d38f8f..0000000 --- a/gitsync.json +++ /dev/null @@ -1,73 +0,0 @@ -{ - "root": { - "name": "template", - "url": "https://github.com/nobl9/go-repo-template.git" - }, - "ignore": [ - { - "fileName": "golangci linter config", - "regex": "^\\s*local-prefixes:" - }, - { - "repositoryName": "terraform provider", - "fileName": "golangci linter config", - "hunk": { - "lines": "@@ -25,4 +24,0 @@", - "changes": [ - "- # Resource descriptions or deprecated notices.", - "- - linters:", - "- - lll", - "- source: \".*(Description|Deprecated): .*\"" - ] - } - } - ], - "syncRepositories": [ - { - "name": "sdk", - "url": "https://github.com/nobl9/nobl9-go.git" - }, - { - "name": "sloctl", - "url": "https://github.com/nobl9/sloctl.git" - }, - { - "name": "terraform provider", - "url": "https://github.com/nobl9/terraform-provider-nobl9.git" - } - ], - "syncFiles": [ - { - "name": "golangci linter config", - "path": ".golangci.yml" - }, - { - "name": "markdown linter config", - "path": ".markdownlint.yaml" - }, - { - "name": "renovate config", - "path": ".github/renovate.json5" - }, - { - "name": "release drafter config", - "path": ".github/release-drafter.yml" - }, - { - "name": "release notes script", - "path": ".github/scripts/release-notes.sh" - }, - { - "name": "issue templates config", - "path": ".github/ISSUE_TEMPLATE/config.yml" - }, - { - "name": "pull request check workflow", - "path": ".github/workflows/pr-title.yml" - }, - { - "name": "release drafter workflow", - "path": ".github/workflows/release-drafter.yml" - } - ] -} diff --git a/go.mod b/go.mod index 7f6fa08..872cecf 100644 --- a/go.mod +++ b/go.mod @@ -1,3 +1,3 @@ -module github.com/nobl9/your-module-name +module github.com/nobl9/govy go 1.22 diff --git a/internal/internal.go b/internal/internal.go deleted file mode 100644 index 3bbace6..0000000 --- a/internal/internal.go +++ /dev/null @@ -1,20 +0,0 @@ -// Package internal holds private application and library code. -// -// This is the code you don't want others importing in their applications or libraries. -// Note that this layout pattern is enforced by the Go compiler itself. -// -// You can optionally add a bit of extra structure to your internal packages to separate -// your shared and non-shared internal code. -// It's not required (especially for smaller projects), but it's nice to have visual -// clues showing the intended package use. -// Your actual application code can go in the /internal/app directory (e.g., /internal/app/app) -// and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/private). -// -// Source: https://github.com/golang-standards/project-layout#internal -package internal - -// GetHello is not accessible outside this module. -// It is a private function, and thus not part of the public contract. -func GetHello() string { - return "Hello" -} diff --git a/pkg/pkg.go b/pkg/pkg.go deleted file mode 100644 index bdffbef..0000000 --- a/pkg/pkg.go +++ /dev/null @@ -1,24 +0,0 @@ -// Package pkg hold the library code that can be used by external applications (e.g., /pkg/public). -// -// Other projects will import these libraries expecting them to work, so think twice before you put -// something here :-) -// Note that the internal directory is the right way to ensure your private packages are not importable -// because it's enforced by Go compiler. -// The /pkg directory is a good way to explicitly communicate that -// the code in that directory is safe for use by others. -// -// It's also a way to group Go code in one place when your root directory contains lots of non-Go -// components and directories making it easier to run various Go tools. -// This is a common layout pattern, but it's not universally accepted and some in the Go community -// don't recommend it. -// -// The pkg directory origins: The old Go source code used to use pkg for its packages and then various -// Go projects in the community started copying the pattern (see this Brad Fitzpatrick's tweet for more context). -// -// Source: https://github.com/golang-standards/project-layout#pkg -package pkg - -// GetWorld is part of the public contract of this library. -func GetWorld() string { - return "World" -}