Use pyiron actions

[liamhuber]

Formatting contrib to use pyiron/actions as though it had been created from pyiron_module_template.

[github-actions]

Pull Request Test Coverage Report for Build 4920731341

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 13.698%

---

Totals
Change from base Build 4920471622:	0.0%
Covered Lines:	1695
Relevant Lines:	12374

---

💛 - Coveralls

[liamhuber]

Unit tests failure:

Could not solve for environment specs
The following package could not be installed
└─ randspg 0.0.1**  does not exist (perhaps a typo or a missing channel).

This is totally correct. The conda-forge package does not exist for windows. I guess the RandSpg job should be wrapped in an ImportAlarm to resolve the issue? Not sure if further edits will be necessary to make sure the notebooks are ok. Also, this package is listed in .ci_support/environment.yml but not setup.py, which seems bad to me.

EDIT:

Not sure if further edits will be necessary to make sure the notebooks are ok.

Actually, these should be fine since notebooks run on ubuntu-latest anyhow; the randspg example book already finished fine.

EDIT:
Ok, what I'm actually trying here is to just move randspg out of .ci_support/environment.yml entirely, and shift it over to .ci_support/environment-notebooks.yml. Since it has no unit tests, I think missing the installation will not hurt us since we still have it for notebooks (where it does appear, but which only run on ubuntu in our CI so it's all good), and since the dependency doesn't actually appear in either of setup.py or on the conda-forge feedstock.

[liamhuber]

benchmark-tests failure:

CoverageWarning: No data was collected. (no-data-collected)
  self._warn("No data was collected.", slug="no-data-collected")
Error: Process completed with exit code 1.

Indeed, this directory is empty. I guess putting a placeholder test there will probably resolve things.

[liamhuber]

build-notebooks failure:

Input Notebook:  notebooks/workflow_example.ipynb
Output Notebook: notebooks/workflow_example-out.ipynb
...
Executing:  98%|█████████▊| 43/44 [00:12<00:00,  3.36cell/s]
...
Exception encountered at "In [23]":
...
File /usr/share/miniconda3/envs/my-env/lib/python3.10/site-packages/pyiron_base/jobs/job/runfunction.py:540, in handle_failed_job(job, error)
    538     if job.server.run_mode.non_modal:
    539         state.database.close_connection()
--> 540     raise RuntimeError("Job aborted")
    541 else:
    542     return True, out

RuntimeError: Job aborted

I bet Lammps isn't in the notebook env. Yup:

+ lame                                  3.100  h166bdaf_1003            conda-forge/linux-64     508kB
+ latexcodec                            2.0.1  pyh9f0ad1d_0             conda-forge/noarch        18kB

But why isn't it there? It's in .ci_support/environment-notebooks.yml. Ah, I bet I need to tell the CI explicitly to use that. Yep, there's a notebooks-env-files kwarg for the reusable workflow. Added and committed.

[liamhuber]

@srmnitc I can't remember which repo you had planned to convert to using pyiron/actions, but here's a non-trivial example of the conversion. Basically just copied and pasted in all the missing files from pyiron_module_template (updating repo name as needed) and then resolved this issues.

[liamhuber]

@niklassiemer, I'm hitting you with the review in the hopes of creating some lasting institutional memory on this process ;)

I don't think it's necessary or productive to review line-by-line, but you may wish to compare what was in .github/workflows before and after the fact, and look at my comments to see the types of errors that can come up when transitioning repos like this.

[niklassiemer]

I had a look at the workflow files - the rest seems to be black :)

[niklassiemer]

Maybe we should start to trust "black" and review before running the black. If approved, fix the black and merge? Another option would be to run black on push to main on the main branch such that we always automatically stay black.

[liamhuber]

Maybe we should start to trust "black" and review before running the black. If approved, fix the black and merge? Another option would be to run black on push to main on the main branch such that we always automatically stay black.

I'm open to it. I think I would prefer to stay black, as I really am finding it easier to read. Let's discuss this at the meeting on Monday.

The nice thing about the centralized CI is that if we decide to go this route, we can just make it so in the centralized workflow, e.g. push-pull-main.yml, and we'll get the behaviour across all the centralized repos!

[liamhuber]

I had a look at the workflow files - the rest seems to be black :)

Thanks, and good catch on the leftover ontology reference!!!

[liamhuber]

Don't worry about test failures; github is currently experiencing issues. Updates here

[liamhuber]

@srmnitc, I'm pretty sure base and atomistics have additional workflows not yet covered in the centralized CI (e.g. base's integration tests with the other repos, which actually should probably never be in the centralized CI since they're base-specific), so getting them converted won't be as simple as a wholesale replacement of .github/workflow scripts. Nontheless, I hope this PR is informative.