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
I think it's time to finally separate out the MAD-X build into its own package. This will have the following advantages:
relatively fast cpymad CI builds (can simply download prebuilt madx library)
decrease in complexity of the build recipe: remove stages, caching caching complexity has decreased with migration to github actions, probably simpler than setting up separate packages
fixes the issue that makes pull requests from external collaborators always error in the first stage (because they don't have access to the secret github token that is required to transfer artifacts between stages) fixed by migration to github actions
we could make it easier for users to build/install cpymad without having to build madx
The text was updated successfully, but these errors were encountered:
I noticed that MAD-X produces a library build for cpymad as part of its travis workflow. This got me thinking we could directly publish that library when a MAD-X release is performed (let's say release additional .dll and .so assets on the github release page), so that cpymad users can install from the "official" release - significantly reducing build complexity on our end (and not really increasing it on MAD-X end).
I will in any case create corresponding github actions that produce this output. I can do it in a separate repository, or as pull request for MAD-X (which would be somewhat more natural/easy).
If doing a PR I could also directly replace the travis build with github actions. Some advantages being that it also runs on windows, is better integrated in the github UI and github API, and more easily allows defining concurrent workflows than travis. Btw: github actions also supports macos, so that would be possible too, but since I don't use mac personally, I don't feel competent to set this up. I'd be better if someone else with access to a mac adapted the linux build scripts afterwards.
I think it sounds great! (and huge thanks for the recent update!). Could you set up in the PR to MADX a github action in parallell to Travis? Like that we could experiment a bit leaving the old Travis. Laurent should be back next week, I am sure he has all the knowledge to setup the macos build...
I think it's time to finally separate out the MAD-X build into its own package. This will have the following advantages:
decrease in complexity of the build recipe: remove stages, cachingcaching complexity has decreased with migration to github actions, probably simpler than setting up separate packagesfixes the issue that makes pull requests from external collaborators always error in the first stage (because they don't have access to the secret github token that is required to transfer artifacts between stages)fixed by migration to github actionsThe text was updated successfully, but these errors were encountered: