Separate benchmark and examples

[aman00323]

Hey @satyrius,

• Currently, we are having multiple modules inside one repo which will not allow us to build in GitHub action.
• We can rewrite the benchmark as part of testing, and examples will be covered in the readme file.
• After that we can use the GitHub action for the test case.

Let me know your thoughts on this!

I would like it to take it further

[satyrius]

Hello @aman00323

Currently, we are having multiple modules inside one repo which will not allow us to build in GitHub action.

The repository structure is ancient. It was created in the era of first releases of golang and there was no standard solution for modules. It was just go get. It didn't change since then, because I'm coding primarily in nodejs now.

We can rewrite the benchmark as part of testing, and examples will be covered in the readme file.

The reason I set up examples running on CI was an extra assurance that software works. We can add missing bits to unit tests (if needed) and skip running examples. Though I like having ready to use code that a developer can execute right after cloning the repo.

After that we can use the GitHub action for the test case.

I'd love to move from Travis to GitHub actions

Action Plan

• brush up the repository structure to meet modern golang standards
• setup github actions

Please feel free to take care from now. But please move forward with small PRs that fixes/improves one thing at a time.

[aman00323]

Please feel free to take care from now. But please move forward with small PRs that fixes/improves one thing at a time.

Sure @satyrius

I will start with brushing the existing structure, then we will pick GitHub action.

Also, I would like to suggest adding a few GitHub bots or actions that our life makes easier.

https://github.com/marketplace/pull-request-size
https://github.com/dependabot
https://github.com/marketplace/stale

[aman00323]

@satyrius I would like to discuss one more thing, How we see this package in the future.

• Because if we want to make it a golang package, then we would be making another repository that contains examples
• Also we can add a docker image of an example, where you pass the log file path as an argument and you will get output in stdout

based on this decision it would make it easy to separate two things

1. it will be golang package anyone can use inside their codebase.

2. we will be providing docker and examples using gonx which will be ready to run (even we can publish binaries) (separate repository)

[satyrius]

I'm would like to have everything in one place. It should not affect the build for any dependable project anyway. Please, provide me example of famous golang libraries that have examples and Dockerfile and what not, so we can use it a a guide.

[aman00323]

Dockerfile context is here if we want to serve user ready-to-use library just like the example.

here is one example that I am aware of right now.

https://github.com/kscarlett/nginx-log-generator

[satyrius]

Alright! Looking forward to seeing pull requests from you.

[aman00323]

@satyrius Please review for our first check point

#53

I will make PR for the benchmark (which needs to be added in testcase)

[aman00323]

@satyrius I have one more suggestion, what if we add auto-release with GitHub action? So when we merge into master it would make a new tag so we don't need to release

[satyrius]

We can make it after we finished with the refactoring. We'll release a new major version and will add some "version bump" action

[aman00323]

@satyrius would you add me as collaborator, so i can avoid pushing from my repo everytime.

[satyrius]

@aman00323 sure thing! I sent you the invite

[aman00323]

thanks, @satyrius