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

Separate madx builds into its own package #63

Open
coldfix opened this issue Aug 26, 2020 · 2 comments
Open

Separate madx builds into its own package #63

coldfix opened this issue Aug 26, 2020 · 2 comments

Comments

@coldfix
Copy link
Member

coldfix commented Aug 26, 2020

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
@coldfix
Copy link
Member Author

coldfix commented Aug 30, 2020

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

@tpersson @rdemaria What do you think about this?

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.

@rdemaria
Copy link
Collaborator

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...

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