-
Notifications
You must be signed in to change notification settings - Fork 3
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
DAG Paths #931
DAG Paths #931
Conversation
The DAGs are being saved in a DAG directory within the directory they specify right now. So running If someone doesn't want to make the dags directory they can use the --no-dag-dir and the dags will just be saved in the directory they specify. You can now make multiple versions of the DAGs. The current one is $SHORT_ID.png, and then the other ones are $SHORT_ID_v1.png, $SHORT_ID_v2.png ... where v1 is the oldest I'm saving the final dag to the workflow directory which then gets saved to the archive directory. I updated documentation for these changes. I haven't changed how things are named yet, which was something in issue 921 and is similar to these changes. |
I can change the names of the dags directory and the actual dags themselves to whatever people think is best. I.e. I can change the $SHORT_ID_dags directory and the $SHORT_ID_dags |
@Leahh02 I like your explanation here and think something like it should be added to the documentation for clarification such as: "The most recent version is $SHORT_ID.png and the others are $SHORT_ID_v1.png, $SHORT_ID_v2.png ... where v1 is the oldest." |
@Leahh02 Would it be useful to have the graphmls in the workflow archive? You mentioned earlier they might be useful for debugging. This looks very good and flexible for the user. If you can fix the tests and make the small documentation change I think we should merge this. |
… of the completed dags can be made
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. I added a comment to the main issue about having a Dockerfile for the neo4j container, so it can be updated in one place. This can be done when the beeflow core pull-deps is fixed though.
I made multiple versions of the DAGs without overriding old versions. I also added an argument to specify where to save the DAGs to. I updated the documentation for this. I wrote this on my personal computer and still need to test it on Darwin.