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

Support building from path to a mine instead of git repo #29

Closed
heralden opened this issue Jul 1, 2020 · 7 comments
Closed

Support building from path to a mine instead of git repo #29

heralden opened this issue Jul 1, 2020 · 7 comments

Comments

@heralden
Copy link
Member

heralden commented Jul 1, 2020

It seems important to be able to build a mine by its path instead of passing a git repo as an argument.

We would have to add a new argument for this, and handle it by creating a volume to mount that dir in the intermine_builder container.

@22PoojaGaur
Copy link
Member

Hi @uosl

I think this would require two changes -

  1. Adding and passing flag for the path in intermine_boot
  2. Updating build.sh in docker-intermine-gradle to go into that folder if path is specified.

Does it seem fair to you? or am I missing something?

@22PoojaGaur
Copy link
Member

For changes in docker-intermine-gradle, I still create a PR in the docker-intermine-repo right?

(And somehow update the git submodule to fetch that version in intermine_boot?)

@heralden
Copy link
Member Author

Adding and passing flag for the path in intermine_boot

👍

Updating build.sh in docker-intermine-gradle to go into that folder if path is specified

Not sure about this, since we'll need to make the dir available by passing it as a volume. Currently, we mount a biotestmine volume and cd into it, right? I think we should mount a volume with the dir the path points to, and cd into that (which should only be one level deep).

For changes in docker-intermine-gradle, I still create a PR in the docker-intermine-repo right?
(And somehow update the git submodule to fetch that version in intermine_boot?)

👍
For testing you might want to replace the submodule with a symlink to your local docker-intermine-repo folder, as I'm not sure how easy it is to get a submodule to stay up-to-date with your local repo when you're trying things out.

@22PoojaGaur
Copy link
Member

22PoojaGaur commented Jul 10, 2020

Not sure about this, since we'll need to make the dir available by passing it as a volume. Currently, we mount a biotestmine volume and cd into it, right? I think we should mount a volume with the dir the path points to, and cd into that (which should only be one level deep).

oh, right. If the folder biotestmine (or MINE_NAME) exist it should be able to use it. I'll see.

For testing you might want to replace the submodule with a symlink to your local docker-intermine-repo folder, as I'm not sure how easy it is to get a submodule to stay up-to-date with your local repo when you're trying things out.

ok.

@22PoojaGaur
Copy link
Member

22PoojaGaur commented Jul 15, 2020

@uosl

I added a flag for datapath (datapath is a folder under which biotestmine would be present). If the flag is provided, it loads the datapath instead of creating new volumes.

For testing I just cloned the biotestmine repo in a datapath folder and pass datapath as command line argument. I think this is not sufficient, as other folders (eg dump, configs, packages) are required during intermine build.

So my question is, in building mine from path do I assume that these folders are present and the intermine_boot just needs to start the webapp ?

If not, what should I do?

@heralden
Copy link
Member Author

I think the datapath folder should only replace the biotestmine volume, while the other volumes (dump, configs, packages, and intermine) should still be created and loaded as volumes.

Let me know if I misunderstood and this doesn't answer your question clearly.

@22PoojaGaur
Copy link
Member

Yes, that's what I was asking.

Got it.

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

No branches or pull requests

2 participants