-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Containerized set metadata #17164
base: dev
Are you sure you want to change the base?
Containerized set metadata #17164
Conversation
c429262
to
e8db1d1
Compare
|
96516d2
to
14889e8
Compare
Would it be a good idea to document this, e.g. in the job_conf.sample.yml or docs. Maybe with usecases, ie when this should be used. Guess this works only (and makes sense) in containerized job destinations? |
Sure, once this is working and we've agreed on the details. |
809411a
to
0f48828
Compare
0d12e60
to
91734a2
Compare
It's only used in API responses and the tool panels. We surely don't want to load edam data when loading the registry while setting metadata.
That happens when `$tool_directory` is part of the mount string and we set `tool_directory` to None for the metadata container.
Boy is this silly. I really love that TS is smarter with this.
this used to be wrong if the app-wide default `outputs_to_working_directory` conflicts the destination's `outputs_to_working_directory`.
8890acb
to
3333b7d
Compare
3333b7d
to
57d7858
Compare
This is how it's enabled:
inside your environment (see integration test). The image is of course not published yet.
docker build -f packages/job_execution/Dockerfile . -t galaxyproject/galaxy-job-execution
to build the image if you want to play with something that is not the integration test.How to test the changes?
(Select all options that apply)
License