You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When going through our repos, I realized that not all do actually contain a documentation (e.g. structuretoolkit) in the form of a doc/ directory, containig files conf.py and index.rst as it is expected by e.g. push-pull-main.yml.
Also, in structuretoolkit, there is a mini workflow, which only runs unit-, benchmark- and integration-test on a minimal environment, I mentioned this also here, so only a subset of the stuff push-pull-main.yml is doing. I changed the workflow there, to use our centralized actions, which was mainly copy-pasting from push-pull-main.yml.
What do you think about adding non-required conditionals to our workflows? We could set a variable like run_build-doc, which defaults to run_build-doc: 'true' and add a boolean eval before each segment, e.g.
However, I haven't yet found anything explaining me, how to actually use a variable of type bool or so, so this can only be done via strings 'true' and 'false'.
In the calling workflow, one could then control which parts of the 'central workflow' are executed. I hope, this further reduces the need to have really customized workflows in repositories to do stuff as described above.
The text was updated successfully, but these errors were encountered:
Hmm, I have mixed feelings. On the one hand, I am favourably biased towards providing more flexibility. On the other hand, I want non-conforming projects to get hit with red flag. For instance, for docs I see no reason that we should not require the bare minima of an API documentation page (which auto-converts docstrings); this is already provided in the module template, so in this case I see a positive feedback loop encouraging us to just use the template whenever possible.
Similarly for the mini workflow, I see how this flexibility would make it easier to accomplish that using the centralized CI...but I am still waiting on a response to that issue to see why we are doing mini to start with; with the rest of the centralized CI in place, I don't really see an advantage in having this.
So I'm really not against this, but I would suggest that we proceed with caution before putting the time in to make things flexible. I think my concerns are best summed up with the english colloquialism "just enough rope to hang ourself" (in the causing ourselves trouble sense, not the criminal liability sense 😝)
When going through our repos, I realized that not all do actually contain a documentation (e.g. structuretoolkit) in the form of a
doc/
directory, containig filesconf.py
andindex.rst
as it is expected by e.g.push-pull-main.yml
.Also, in
structuretoolkit
, there is amini
workflow, which only runs unit-, benchmark- and integration-test on a minimal environment, I mentioned this also here, so only a subset of the stuffpush-pull-main.yml
is doing. I changed the workflow there, to use our centralized actions, which was mainly copy-pasting frompush-pull-main.yml
.What do you think about adding non-required conditionals to our workflows? We could set a variable like
run_build-doc
, which defaults torun_build-doc: 'true'
and add a boolean eval before each segment, e.g.However, I haven't yet found anything explaining me, how to actually use a variable of type bool or so, so this can only be done via strings
'true'
and'false'
.In the calling workflow, one could then control which parts of the 'central workflow' are executed. I hope, this further reduces the need to have really customized workflows in repositories to do stuff as described above.
The text was updated successfully, but these errors were encountered: