lakeFS
lakeFS copied to clipboard
treeverse
ACLs: Use fluffy in CI workflows
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Setup
I think that from all possible options this might be the worst one. The worst thing we can do is to start to pick and choose which tests are running in the esti jobs. The tests are basically divided to 2 in this matter:
- Uses auth operations - require auth server
- Doesn't user auth operation - doesn't require auth server
I see no point in splitting execution just to run 2 distinct lists of tests. I also don't understand how we can choose what is the right combination to run with auth server and what should we run without. Should it be AWS / Azure / GCP, with/without external DB? I don't see any educated decision we can make here.
If this is the case - I prefer going with the original design decision to use the acl server for testing!
Setup
I think that from all possible options this might be the worst one. The worst thing we can do is to start to pick and choose which tests are running in the esti jobs. The tests are basically divided to 2 in this matter:
- Uses auth operations - require auth server
- Doesn't user auth operation - doesn't require auth server
I see no point in splitting execution just to run 2 distinct lists of tests. I also don't understand how we can choose what is the right combination to run with auth server and what should we run without. Should it be AWS / Azure / GCP, with/without external DB? I don't see any educated decision we can make here.
If this is the case - I prefer going with the original design decision to use the acl server for testing!
If you test everything with external-auth, then you'll miss some important coverage for the simple-auth. For example, setup of lakeFS with simple-auth and the entire authorization system for all actions. For coverage reasons, I suggested at least 1 external-auth and 1 simple-auth. I think that duplicating all test suites for no-auth is extremely wasteful, that's why I suggested to split the existing tests. I agree there isn't an educated way to decide the proper combination for each. If you prefer you can duplicate one of the suites and have it tested with no-auth too.
Setup
I think that from all possible options this might be the worst one. The worst thing we can do is to start to pick and choose which tests are running in the esti jobs. The tests are basically divided to 2 in this matter:
- Uses auth operations - require auth server
- Doesn't user auth operation - doesn't require auth server
I see no point in splitting execution just to run 2 distinct lists of tests. I also don't understand how we can choose what is the right combination to run with auth server and what should we run without. Should it be AWS / Azure / GCP, with/without external DB? I don't see any educated decision we can make here. If this is the case - I prefer going with the original design decision to use the acl server for testing!
If you test everything with external-auth, then you'll miss some important coverage for the simple-auth. For example, setup of lakeFS with simple-auth and the entire authorization system for all actions. For coverage reasons, I suggested at least 1 external-auth and 1 simple-auth. I think that duplicating all test suites for no-auth is extremely wasteful, that's why I suggested to split the existing tests. I agree there isn't an educated way to decide the proper combination for each. If you prefer you can duplicate one of the suites and have it tested with no-auth too.
We have one job dedicated to basic auth
Given that we are merging this, please open an issue that this introduces a circular testing dependency and also makes lakeFS untestable without a closed-source component. I would like us to be able to revisit this.
Given that we are merging this, please open an issue that this introduces a circular testing dependency and also makes lakeFS untestable without a closed-source component. I would like us to be able to revisit this.
https://github.com/treeverse/lakeFS/issues/8123