Having an issue with subworkflow `bam_create_som_p...
# linting
m
Having an issue with subworkflow
bam_create_som_pon_gatk
, that is not valid with pre-commit on the pipeline side, but ok from the modules side
m
what is the error?
we should probably add
modules/nf-core
and
subworkflows/nf-core
to
.prettierignore
m
with pre-commit:
Copy code
prettier.................................................................Failed
- hook id: prettier
- files were modified by this hook

modules/nf-core/gatk4/mutect2/meta.yml
subworkflows/nf-core/bam_create_som_pon_gatk/meta.yml
After a TEMPLATE sync and a subworkflows update
why do we have this then in the pre-commit yaml?
Copy code
- id: end-of-file-fixer
        exclude: |
          (?x)^(
              .*ro-crate-metadata.json$|
              modules/nf-core/.*|
              subworkflows/nf-core/.*|
              .*\.snap$
          )$
and I do believe code coming from modules should be pre-commit valid
m
they have the same prettier version in
pre-commit-config.yml
?
the
end-of-file-fixer
is just a replacement for what we had in editorconfig
m
Copy code
diff .pre-commit-config.yaml ../modules/.pre-commit-config.yaml
7a8
> 
9c10
<     rev: v6.0.0
---
>     rev: v5.0.0
PR incoming
m
there you go
m
Any smart idea on how to have a proper sync between TEMPLATE in pipelines and modules?
m
m
Meh
I was more thinking of having a TEMPLATE merge on modules
m
and keeping up with renovate on modules
âž• 1
for that, we should first split up the renovate PRs into infra and module containers
this is not an issue of modules template. more of the modules repo itself
m
Actually given that modules in the pipeline could be old, that is an ok solution for me
it does make sense to ignore linting, but for me, new code coming from modules should always be valid no matter what
m
try running
pre-commit run --all-files
in modules...
m
and since we are not properly in sync for the template in pipelines and modules, that's why I was thinking towards more of a template issue (not module, but pipeline given the pre-commit.yaml files etc)
That'll be for another PR, but yeah, we should do this more often
m