Move tools an acceptance to repository root

[zregvart]

This sets up the acceptance tests as a separate go module and moves acceptance and tools from internal to repository root to better reflect them as modules.

[codecov]

Codecov Report

Merging #327 (c5b3bc2) into main (527202f) will decrease coverage by 0.77%.
The diff coverage is n/a.

❗ Current head c5b3bc2 differs from pull request most recent head c7b267d. Consider uploading reports for the commit c7b267d to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #327      +/-   ##
==========================================
- Coverage   77.33%   76.56%   -0.78%     
==========================================
  Files          45       45              
  Lines        3433     3358      -75     
==========================================
- Hits         2655     2571      -84     
- Misses        778      787       +9     

Flag	Coverage Δ
acceptance	52.79% <0.00%> (+0.08%)	⬆️
generative	4.71% <0.00%> (ø)
integration	90.48% <0.00%> (ø)
unit	60.66% <0.00%> (-1.21%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
internal/evaluator/conftest_evaluator.go	72.04% <0.00%> (-12.70%)	⬇️

[lcarva]

This seems pretty straight forward. If using go 1.18 or newer, it doesn't seem to require any special usage. It just works.

Are there any downsides to this approach? I wonder if there will be any issues with dependabot.

[zregvart]

Are there any downsides to this approach? I wonder if there will be any issues with dependabot.

Seems that dependabot doesn't support workspaces right now, so that's a downside -- I've seen go mod tidy in a module update the go.work.sum file.

Other than that, I was hoping that we could work with dependencies a bit more independent, but that is not the case, so having modules without workspace could be a bit more helpful at the moment. For example, the acceptance tests could run with a different version of docker go API than the CLI, which would help with Testcontainers update (#325). Downside of that, is that I don't think it's good for the projects to drift in versions, an example of that would be tekton/cli vs tekton/pipeline version issue that occurred in #324.

I haven't seen anything that would impede the day to day workflow. We don't really need workspaces, the modules don't depend on each other. An interesting development could be if we were to merge the https://github.com/hacbs-contract/enterprise-contract-controller and https://github.com/hacbs-contract/ec-cli into a single git repository, here workspace would be very beneficial, so if we would like to consider that, this would be a good first step.

[simonbaird]

I can see the "move acceptance tests to their own directory with their own go.mod file" change, but what part of this change is the "create go workspace"?

[zregvart]

but what part of this change is the "create go workspace"?

In essence the go.work and go.work.sum files (https://github.com/hacbs-contract/ec-cli/pull/327/files#diff-70f7e3c361ae136c655130ab253927b5f6e5c987797a095db1bbb1e790930484). The repercussions are in the go.mod files. With go work sync the dependencies get hoisted (or that's my understanding) from modules and then the (newest?) version gets synced down to other modules -- resulting in some version changes that I did not expect when starting on this.

We don't inter-depend between modules so no other changes are visible. If we were, the replace in go.mod that would point to a local directory would be removed.

[simonbaird]

Aha, thanks.

[simonbaird]

Approve FWIW, but I don't have much insight into the pros and cons.

[lcarva]

Have we decided to drop this, at least for now?

[zregvart]

Have we decided to drop this, at least for now?

I'll remove the go.work and go.work.sum files & update the title/commit message.