-
Notifications
You must be signed in to change notification settings - Fork 2
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
Improve artefact workflow #325
Improve artefact workflow #325
Conversation
…`pytest tests` at source directory
Minor documentation update for MetOffice#277.
278 absolute paths in compilation
…ed, as reported by CI pipeline on Github
#5 Fix test warnings
This is now ready. The PR looks so big because the change to the artefact names affected many files, plus I started to fix up files with re to coding standard like line lengths etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This review turned into a real stream of consciousness so probably best to read all the comments before replying to any of them.
Looking at the proposed change, I'm not sure there's any value to continuing to support access by string. If it's only to provide backwards compatibility then I don't think we need to worry since the current release is 1.0 in name only.
Thanks for the review. I have renamed ALL_SOURCE->INITIAL_SOURCE as suggested, and opened #328 to find better names for other artefacts. As requested, I've closed the issues that I think are ok now. I'd suggest to leave the read-only-artefactstore for the telco. Not sure about the special handling of dictionary artefacts - open a ticket for later? |
Oh, I also reformatted some more files to be 80 characters or less (not all of them, some were rather huge, making it hard to see the important changes). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy that conversations have been started around the things I spotted while reviewing this change. The change itself is a clear step forward and basis for future work.
This PR introduces new artefact categories defined as enums. The code (and its typing) supports strings and this enum as keys, meaning any user script can artefacts as they want (and be certain not to interfere with the ones used in Fab).
I then used three new categories for fortan/c/psyclone build files, and updates all steps to keep these categories up-to-date. E.g. when pre-processing a Fortran file, the .F90 would be removed from the fortran-build-files, and the .f90 will be added etc. PSyclone will add the newly created files to the fortran-build-files. This means that e.g. the Fortran analysis step only need to look at two artefacts (C and Fortran), instead of the current one:
New version is now:
This also makes it MUCH easier to add a step (since there is no need to know the internals of Fab to figure out in which artefacts to find the required files). It also fixes (if I am not mistaken) the old approach where .f90 files are copied from src to build during preprocessing, BUT they are never added to an artefact, so the compilation will still be based on files in source.