test spack package on release

[trws]

trafficstars

Discussing this with @grondo, it seems like the way to go is to leverage spack to manage dependencies on travis, pinning versions so we don't get upstream surprises, then one of our travis tests can build with spack diy rather than the usual make to test building under the package manager. We'll probably want to pull the actual package file, which is just a little python blob, into our repository, so that we can update it locally, fix it there, then upstream later.

[grondo]

I looked into switching to spack to manage dependencies over the weekend, and ran into some issues, which may not actually be showstoppers, but makes switching to spack a bit of a pain

• spack doesn't appear to have a way to build only dependencies for a package, it always wants to build and install the target package (and its dependencies). This isn't what we want in travis.
• I didn't see a way to override the spack package file for flux with a locally supplied version
• spack has no binary packages, so it takes a lot longer to pull down and build all dependencies when some may be supplied by OS or pip/luarocks-like package managers.

The last bullet may be mitigated by caching the spack archives, and other items above may have workarounds I didn't discover yet, so I thought I'd post here so more knowledgeable persons could give instruction.

Additionally, it appears that upstream spack is replacing (augmenting?) spack diy with spack setup which might be more what we want, but only supports CMake builds at this time. I'd be willing to attempt to add support for autotools packages to spack setup, but I'd need some serious help with where to start.

[trws]

Some of this can be dealt with.

1. Use spack install --only dependencies <pkg> to install the dependencies only, with this I would say use DIY or setup for at least one test to test the package itself.
2. There are patches in the works for this, but unfortunately you're right for now. The only way to do it currently is to either set up a local mirror directory or copy the darn thing over the flux/package.py file, neither of which is terribly satisfactory.
3. This is also WIP, see here. In the meantime, caching is basically the option as far as I can tell, which again is not terribly satisfactory. The other option is to build a package.yaml file that informs spack of the existence and version of packages installed through apt. It's more work than just having spack build it, but if there are problematically large packages it may help.

The whole spack setup thing is a bit interesting. It grew out of a third party effort, and I have no idea where it's going. Using it for development could be useful, but I don't know if it would be worth the effort to port it for autotools unless it would be helpful day to day.

[grondo]

Thanks @trws, this is exactly the help I was looking for! I think with your suggestions it will be easy to switch to spack, even with the caveats, and we'll end up with a much more maintainable travis environment. (Somehow I hadn't found the --only dependencies option to install...)

[grondo]

Pushing this a bit further, it does seem like our flux spack spec probably needs an update in the repo. Also, to work for all dependencies we use in travis, we'd also need to add package specs for lcov and libfaketime, which possibly won't be too difficult.

[SteVwonder]

Additionally, it would be cool if we had a buildbot nightly build that used spack install flux directly. Mainly to be notified when the spack package breaks.

[trws]

That has been on my list for a while… actually, I have a patched version of our spack package that needs to be upstreamed from the splash stuff. I’ll try and get to that today, then see about linking it over here.

On 17 Jul 2018, at 11:06, Stephen Herbein wrote:

Additionally, it would be cool if we had a buildbot nightly build that used spack install flux directly. Mainly to be notified when the spack package breaks.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/flux-framework/flux-core/issues/920#issuecomment-405674249

[SteVwonder]

Thanks @trws, that would be a significant help to me.

[garlick]

Mentioning @vsoch so she can make sure this issue gets closed by her work when complete. Or if it's out of date, feel free to close it now.

[vsoch]

This workflow is complete - but we need to add the on release event here: https://github.com/flux-framework/flux-spack/blob/a204abd2bbbc924fa2ff30d8930ffe5b5bafb32d/.github/workflows/test-build.yaml#L3-L6 and the PR into spack needs to be reviewed / merged so changes here can then be easily added there. I'll open a PR to add the release event soon.

[vsoch]

@grondo we could also have a release trigger with the container build in the current repository. When that is working, it should build with spack, and we could modify to use a release. I'm not sure there is a good way (aside from giving a PAT) to a separate repo to trigger on a different repo's release.

[vsoch]

Is there still something we need to do here? The repository here https://github.com/flux-framework/spack/ has been working fairly well to regularly test builds and update packages in upstream spack. If we are good with that, we can close the issue here.

[grondo]

Thanks! Closing.