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

Add test for PRs to main staying in one analysis folder (or shared folders such as docs, tests, etc) #243

Open
lemireg opened this issue Sep 9, 2024 · 3 comments

Comments

@lemireg
Copy link

lemireg commented Sep 9, 2024

add a test and/or warning when a commit to a repo generated by VISCtemplates has work across multiple analysis folders. For example:

https://github.com/FredHutch/Hassell750Analysis/commit/b3b9ddef3700197c896a4afe3e1fa8635b0e7a40

which contains changes to ADCC and BAMA. (Maybe Gabby can write/implement this test? Maybe with Dave's help? Could start in just one of my own repos to demo it?)

@slager
Copy link
Contributor

slager commented Sep 10, 2024

To me this doesn't really sound like a VISCtemplates issue, it sounds more like a git best practices issue that could be addressed in VISC/SRA git training/documentation. Specifically, git commits should be atomic, i.e. a single commit should only change one "thing".

I wouldn't advise that we try automating this. Checking that there are changes to only 1 analysis folder at a time can be done by the user right before making the commit by routinely checking git status prior to doing git commit. A pull request reviewer could also check that the list of changed files/folders in a PR only involves one analysis.

@lemireg
Copy link
Author

lemireg commented Sep 11, 2024

ops! I meant a test for a new PR to main/master (not a commit). Do you still think it's not something to test @slager ?

@lemireg lemireg changed the title Add test for commits staying in one folder Add test for PRs to main staying in one analysis folder (or shared folders such as docs, tests, etc) Sep 11, 2024
@slager
Copy link
Contributor

slager commented Sep 11, 2024

Yeah, in my opinion it sounds more like something that would go in SRA best practices documentation/training, or on a checklist for what to look at before merging a PR, rather than something that we'd want to make explicit automated tests for.

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

No branches or pull requests

2 participants