Open keighrim opened 3 years ago
I'm pushing for the term app directory instead of toolsheld, as you mentioned that what we are putting inside are apps.
On top of the points @marcverhagen mentioned in the above comment, I'm adding some more of my thoughts;
Dockerfile
, but maybe some more) in the app repo, and reject if they don't exist. Dockerfile
in the repo, start a container and query for app metadata, upload the image to the docker hub or the github container registry. Reject the PR if the app metadata is invalid, or docker build fails. docs
directory (e.g. docs/edu.brandeis.llc/kaldi/x.y.z/index.html
) and add a commit to the PR. docs
(e.g. docs/apps.html
, docs/vendors.html
, and/or docs/index.html
) .There may be a need for namespaces in the directory, but I am not yet convinced. It is probably not right to use the term vendor by the way. Are we really the vendor of https://apps.clams.ai/edu.brandeis.llc/kaldi/x.y.z and is hipstas really the vendor of https://apps.clams.ai/hisptas/kaldi/a.b.c? We have a distinction between tools and apps. The tools are from vendors and they should be mentioned in the app metadata. We do the apps and if somebody else does an app they can get their own app directory. If all that is true then we do not need namespaces for vendor reasons. However, we could choose to use subdirectories video
, audio
, images
and text
or any other logical division.
For the build and publication automation, I would suggest to do a few by hand first to see what automation steps make sense. What there is above in the bullet points makes sense in general, but I will for now admit that I am not a great fan of github actions after my first failed attempt to understand them.
Some remarks on the bullets:
Perhaps something like author
or maintainer
would make sense instead of vendor at the app level
Automatically generate a HTML version of the app metadata in docs directory (e.g. docs/edu.brandeis.llc/kaldi/x.y.z/index.html) and add a commit to the PR.
This can't be done if the PR sent from a third party fork, where clams-bot
do not have push permit.
(With all the recent hard work on the app metadata implementation, app template implementation, and some help from ghcr and gha)
Introducing the first prototype app directory, made available by
clams-python
release)And the first app registration is submitted at #31 via https://github.com/clamsproject/app-spacy-wrapper/actions/runs/4973069451.
(spacy-wrapper
got the update a bit earlier as my testbed)
Now looking back at the initial checklist from @marcverhagen ;
and mine;
https://apps.clams.ai/
base url as first-party only. Thrid party apps should have their own app identifier with their own base url (doesn't matter a web page is behind the identifier or not).clams develop
app template (https://github.com/clamsproject/clams-python/pull/137))NAME
, TAG
, CONTAINER
variables (using an issue template might be a good way to do this)Run workflow
button. Dockerfile
, but maybe some more) in the app repo, and reject if they don't exist.
Dockerfile
in the repo, start a container and query for app metadata, upload the image to the docker hub or the github container registry. Reject the PR if the app metadata is invalid, or docker build fails. docs
directory (e.g. docs/edu.brandeis.llc/kaldi/x.y.z/index.html
) and add a commit to the PR.
docs
(e.g. docs/apps.html
, docs/vendors.html
, and/or docs/index.html
) .
Future todo list;
32
33
34
42
(original comment) Moving the below comment from https://github.com/clamsproject/appliance/issues/2, as it seems more suitable in this repo.
@marcverhagen commented on Oct 8 A slightly different, but overlapping, issue is what needs to be in the application's metadata and/or the toolshed to make this work. Most of the things that go into
tool.xml
qualify (but maybe not input and output name). And somewhere the script needs to know where the repositories are. I was first thinking that could be part of the metadata, but I know think that maybe it should be in the toolshed and that the process that creates the toolshed adds the repository URL.Not sure whether anybody gave some thoughts as to what the toolshed would look like, so I will just throw out some loose thoughts for discussion:
It is a bit weird to call this a toolshed because what we put in the shed are app, but appshed sounds like ape shit.