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

how to handle config/gpi_pipeline_primitives.xml in git #104

Open
mperrin opened this issue Oct 12, 2016 · 3 comments
Open

how to handle config/gpi_pipeline_primitives.xml in git #104

mperrin opened this issue Oct 12, 2016 · 3 comments

Comments

@mperrin
Copy link
Contributor

mperrin commented Oct 12, 2016

The config/gpi_pipeline_primitives.xml file has to be auto-generated by the "Rescan Pipeline Config" whenever new primitives are added. Since it's a machine-generated data file it probably shouldn't be in the version control system. If it is, then it adds more work to frequently commit changes to that which don't really need to be tracked since it's derived from primitives metadata.

But if we take it out, that means that everyone is going to have to remember to rescan their pipeline configs when they pull in new changes, and new users are going to need to do that after installing the pipeline before they can run it. So that adds extra steps too.

Which is preferable? @semaphoreP @kfollette opinions?

@astrofitz
Copy link
Contributor

Could the rescan could be done in a pull hook?
e.g. something akin to https://gist.github.com/sindresorhus/7996717 https://gist.github.com/sindresorhus/7996717
Mike

On Oct 12, 2016, at 6:25 AM, Marshall Perrin [email protected] wrote:

The config/gpi_pipeline_primitives.xml file has to be auto-generated by the "Rescan Pipeline Config" whenever new primitives are added. Since it's a machine-generated data file it probably shouldn't be in the version control system. If it is, then it adds more work to frequently commit changes to that which don't really need to be tracked since it's derived from primitives metadata.

But if we take it out, that means that everyone is going to have to remember to rescan their pipeline configs when they pull in new changes, and new users are going to need to do that after installing the pipeline before they can run it. So that adds extra steps too.

Which is preferable? @semaphoreP https://github.com/semaphoreP @kfollette https://github.com/kfollette opinions?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #104, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVoDsnRv0lvw-Bm-d80uSxlqUksDYXJks5qzN_dgaJpZM4KUwEO.

@semaphoreP
Copy link
Contributor

Correct me if I'm wrong, but I believe the hooks are not on version control so we'd something like a script that writes the appropriate git hook into each person's .git directory.

@semaphoreP
Copy link
Contributor

On launch of the pipeline, can we check the date modified of gpi_pipeline_primitives.xml against the date modified of all files in the primitives directory? If any of the primitives have been modified, then we trigger a rescan of the pipeline config on startup of the pipeline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants