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 conditionals to fine-tune job execution #54

Closed
mbruns91 opened this issue Oct 18, 2023 · 1 comment
Closed

add conditionals to fine-tune job execution #54

mbruns91 opened this issue Oct 18, 2023 · 1 comment

Comments

@mbruns91
Copy link
Contributor

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.

if: run_build-docs == 'true'
  build-docs:
      needs: commit-updated-env
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v3
        - uses: pyiron/actions/build-docs@main
          with:
            python-version: '3.11'
            env-prefix: /usr/share/miniconda3/envs/my-env
            env-label: linux-64-py-3-11
            env-files: ${{ inputs.docs-env-files }}

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.

@liamhuber
Copy link
Member

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 😝)

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