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

Workflow version management #6410

Open
3 of 6 tasks
mvdbeek opened this issue Jun 29, 2018 · 9 comments
Open
3 of 6 tasks

Workflow version management #6410

mvdbeek opened this issue Jun 29, 2018 · 9 comments

Comments

@mvdbeek
Copy link
Member

mvdbeek commented Jun 29, 2018

I think it would be great if we could have a little more control over versions. This includes a couple of things (please amend if you have more ideas):

@gregvonkuster
Copy link
Contributor

Way back when workflows were first introduced, I was thinking that a workflow version would be at least partially defined by the versions of the tools contained within the workflow. Workflows have come a long way since then and I've not thought about this for a while, so I'm not sure how relevant it still is. But at the time, I felt that if a workflow layout remains the same (i.e., all tools and connections remain the same), then the action of upgrading a tool within the workflow would somehow increment the version of the workflow. If this no longer makes sense, feel free to ignore. ;)

@hexylena
Copy link
Member

I mentioned some of these points originally in #298, would definitely love to see this!

@mvdbeek
Copy link
Member Author

mvdbeek commented Jun 30, 2018

then the action of upgrading a tool within the workflow would somehow increment the version of the workflow

Right, that is still the case. But we don't have a way to go back and forth between versions currently, which is item 1 on the list. We'd probably also want to be able to exchange versions across galaxy instances without transferring the entire set of Workflow objects associated with the most recent workflow and reference a specific version ("Hey, please run version 1.3 of this workflow"). That'd be the last step.

@mvdbeek
Copy link
Member Author

mvdbeek commented Jan 23, 2019

(deleted comments about fixed bugs, they were confusing me)

@hexylena
Copy link
Member

@mvdbeek you can also "hide" comments with reason: "outdated" which may be better in the future than deleting them :)

@innovate-invent
Copy link
Contributor

I would personally love to see the underlying version management be done by git. Format the json (I would prefer the workflows to be stored in yaml) so that it lends itself to git parsing such as having each tool on a separate line.
Then workflow sharing can be done using your favorite git repository host.
Just provide galaxy with the uri to clone.

@mvdbeek
Copy link
Member Author

mvdbeek commented Mar 11, 2019

I would personally love to see the underlying version management be done by git.

Sure, but that's outside of the scope of Galaxy for now. I think it'll be a mess to deal with branches and untagged commits. We probably want to keep it simple, not going beyond anything more complex than major/minor/patch. I do agree that importing and tracking versions via some URI scheme (item 3 and 4 in the list) would be cool, but someone needs to work out the details.

Now that we have simple date-based internal versions I personally think that extending the utility of parameters, branching and other things that lead to less copy-paste for slightly different workflows is more important. But if someone wants to have a go at it it will be a nice project.

@pcm32
Copy link
Member

pcm32 commented Apr 6, 2019

One thing I've noticed is that when I export a workflow and then re-import it, versions start back from zero. Is this intended or a bug? I would expect versions to be persisted to the exported file. To be clear, when I mean export is by doing Workflow -> My workflow -> Share (drop down menu) -> Download. I have noticed that other avenues produce different output (which is a bit annoying to be honest). Happy to open a different issue for this if needed.

@mvdbeek
Copy link
Member Author

mvdbeek commented Apr 6, 2019

Yes, that is expected. The versions you select now are just internal versions, one per saved change.
Explicit versions are the the last bullet point, but there's a lot of details to consider for implementing this.

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

5 participants