Skip to content
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

GitHub actions ci and refactor #1

Closed
wants to merge 22 commits into from
Closed

GitHub actions ci and refactor #1

wants to merge 22 commits into from

Conversation

obalunenko
Copy link

@obalunenko obalunenko commented Apr 9, 2021

With this PR I add the following enhancements:

  • Follow Go community suggested project layout: https://github.com/golang-standards/project-layout
  • CI/CD support for automation code checks and delivery release artifacts (executables for all platforms that could be downloaded from the repository releases page). Release initiated by adding semver tag https://semver.org/
  • Add makefile automation
  • Helper scripts for compiling, linting, and releasing the application

@obalunenko
Copy link
Author

obalunenko commented Apr 9, 2021

@adonovan Could you please review this PR? 🙏🏻

Demo of how GitHub actions would act:
https://github.com/obalunenko/spaghetti/pull/1/checks
Runs history:
https://github.com/obalunenko/spaghetti/actions/workflows/go.yml

And here is an example of how the releases page will look like after creating a new release with adding git semver tag:
https://github.com/obalunenko/spaghetti/releases

@adonovan
Copy link
Owner

adonovan commented Apr 9, 2021

Follow Go community suggested project layout: https://github.com/golang-standards/project-layout

This is the first time I've heard of this layout. It may well have merits for large projects, but this project is literally two .go files and zero dependencies, so I am not eager to accept this PR. It triples the number of files of code, and adds a huge number of dependencies to the tools submodule (ironically making an ideal candidate program on which to run spaghetti itself), and it doesn't materially improve any of these steps:

  • documentation. The github and pkg.go.dev pages are already perfectly clear and discoverable.
  • testing. There are no tests, so CI test integration has no value.
  • building. The "go build" command is as simple as could be and runs in the blink of an eye.
  • releasing. The project can be trivially installed using the one-line command in the README. Its users are already Go developers; I don't need to tell them to install Go.

The linter check is nice, but it's not important enough to justify this PR.
The version numbering is neat, but again I just don't think it's important enough to complicate the build.

@rsc
Copy link

rsc commented Apr 9, 2021

golang-standards/project-layout#117

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants