GMLC-TDC
HELICS and GridLAB-D codebase management
Due to the HELICs support in GridLAB-D, (and our experience thus far in trying to work with the two codebases) it would be convenient if there was a method of providing a dedicated version of GridLAB-D to the HELICS codebase so that the HELICS developers (who generally do not have write privileges to the GridLAB-D codebase) can update GridLAB-D as HELICS changes without the immediate support of a GridLAB-D developer. I propose the following:
- HELICS sets up a dedicated branch in the GridLAB-D repository (this may already exist).
- Somebody with GridLAB-D write access (probably @trevorhardy for now since @afisher1 is out for a while) takes the responsibility of keeping said branch up to date with changes in other appropriate GridLAB-D branches.
- When changes are needed, the HELICS team forks this dedicated branch and makes changes in it to update it however HELICS needs.
- When those changes are complete, the HELICS team submits a pull-request back into it dedicated GridLAB-D branch.
- The GridLAB-D development team accepts the pull-request and merges the changes into the dedicated branch.
- The GridLAB-D development team either merges the changes in the HELICS branch into a more permanent location or simply continues to keep the branch up to date with the main respository as a whole.
I think this basically ends up looking like a fork-and-PR model I've seen other codebases use.
Any thoughts?
Trevor
HELICS Gridlab-d repo
Is set up, I defaulted it to a HELICS branch for the time being. It contains an updated HELICS builds which I got working based on @eberleim cmake branch of Gridlab-d. I verified it works with MSYS2, haven't done the same on Linux yet though I am working on that.
I am not sure what the plans are for merging @eberleim feature/1091 branch into the Mainline repo for Gridlab-d but it should be possible to merge back into that feature branch regularly.
I am wondering if it might be worth setting up a CI build and test of the HELICS linkages in GridLab-d, then we can make sure it keeps working, and maybe eventually get to a CI build of the tutorial scenarios.
How do we provide pre-built executables / installers for GridLAB-D with HELICS?
For the moment I am just glad I can build the Gridlab-d with HELICS again and have a path to keep it doing so for a while. I suppose we could reasonably tag our own release on our fork with a windows installer, though I have no idea how complicated that will be to automate. Eventually the main release of Gridlab-d should have HELICS linkages regularly so the fork won't be as important.
@phlptp I like the idea of using CI to stay on top of the HELICS linkages but that would require regular merges from the "main" branch of GridLAB-D (probably develop) and forks from the HELICS branch in GridLAB-D, no? Do you have a known way of automating this now?
@kdheepak I believe the GridLAB-D installer construction process is manual so I don't think we'd have an easy way of building and hosting these in the GridLAB-D repo/site. I'm assuming we could do build and host these on the HELICS side and link to them from the GridLAB-D side. These installers would be for a fixed version of GridLAB-D (v4.10, for example) with each new version of HELICS updating that build. When GridLAB-D pushes a new version, we make sure the latest version of HELICS support is pushed back into its repo to be included in the build.
If we can do this in a low-effort way, this would ensure that the latest version of GridLAB-D has an installer that can support the latest version of HELICS. Some of the time that installer would be directly on the GridLAB-D site and sometimes it would be a link back to the HELICS site. This is obviously not ideal and I'm open to suggestions.
If GridLab-D wants (or will take) it we could set their repository up with something to automate building installers for releases, and a nightly build running for a (helics-develop?) branch that pulls from our fork and opens a PR if needed to update their develop branch.
To automate PR opening the workflow would need to live in their repository.
@nightlark, Thanks for the offer. Once I have a better understanding of how we're going to be managing the GridLAB-D codebase while @afisher1 is out, I'll get back to you.
@phlptp and/or @nightlark; do we still have interest in moving forward with this? I opened this issue a few years ago due to a pain point then but I haven't heard much talk about this in recent years. Do we still need a dedicated repo for checking GridLAB-D compatibility as a part of the HELICS project?
I think this is an issue for the GridLab-D repository/project, rather than one that should involve us maintaining a fork. If they don't already have a CI job in place that catches issues when an optional/required dependency (such as HELICS but could include others) releases a new version then one should be set up in their repository that runs on a regular basis to catch those issues.
Based on how long it takes to update some of the language bindings when a new release happens that breaks them, it doesn't seem like we have the resources to also maintain a large set of tool integrations (re: ns-3 bindings still need updating to work with new versions of ns-3 that use CMake with HELICS 3). It's also likely that the person actually fixing the issues will be one of the developers working on both projects (if applicable), so having the tests be in the repository where the changes need to happen will hopefully help it get noticed and addressed sooner.