feat: use generics for config-loader and re-use for int test#165
Open
michaelfedell wants to merge 37 commits intodevelopmentfrom
Open
feat: use generics for config-loader and re-use for int test#165michaelfedell wants to merge 37 commits intodevelopmentfrom
michaelfedell wants to merge 37 commits intodevelopmentfrom
Conversation
Merging v3 golang package namespace change to match deployed version, so users of packages can work
Hot fixes for new release
Releasing diffraction detector which saves detector field. Also releasing permissions standardisation and documentation updates
Merge DOI changes to main
Public Access
…ch the dataset ID, will need to think about this for future imports. Also clearer printing of what was downloaded as importer runs
…y to switch between pseudo-intensity definitions based on something. Don't know what that is yet, reached out via email to releavant people
Feature/importer fixes
Added a hack to allow this G090 dataset to import, the RTT doesnt mat…
Make detector config GET work on public permission
…for sol847, in which case we load the new pseudo-intensity file
Added importer change to check if dataset ID is greater than the one …
Bug fixes, pseudo-intensity standards change
Fix test affected by importer logging output change
v3.7.0 release
Fixed pseudo-intensity check
Release 3.8.0
Update catalog-info.yaml
…ts, it imports the one with lowes t SCLK and logs this. This is a workaround for GDS delivering us badly named files as happened recently
Modified importer so in cases where it finds more files than it expec…
Removed cloudwatch logging from API and quant job runs
Mergemain
Want to load the config struct for integration tests in the same way as we do for the API (load from json file and then override based on PIXLISE_CONFIG_* environment variables). To do this, I refactored config loader functions to use generics; had to just use `T any` types :/ Then changed the integration tests to use a single configPath flag instead of a big set of os args; config-loader tests still passed though I've not yet tried building and running the actual integration tests
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Want to load the config struct for integration tests in the same way as we do for the API (load from json file and then override based on PIXLISE_CONFIG_* environment variables). To do this, I refactored config loader functions to use generics; had to just use
T anytypes :/Then changed the integration tests to use a single configPath flag instead of a big set of os args; config-loader tests still passed though I've not yet tried building and running the actual integration tests