What do you think about a receipe repository

1

Hello @cytopia and all Devilbox community

What do you think about a receipe repository for user contribution ?

There are lot of other idea and solution not yet integrated in Devilbox 1.0

I like current version, that help me day after day to work better. But I’ve also added some other containers with docker-composer.overrride.yml.
And i’m pretty sure that we could share solutions between community.

This principle already exists with

Regards
Laurent Laville

2 Likes
2

That is a pretty good idea and can actually be tackled very quickly.

Update:

I changed recipes to flames, just to stick a bit closer to the project name.

Quick idea

I’ve had some thoughts and this is a rough idea about the devilbox/flames repository

Directory structure

README.md
flames/
    <user>/
        <service>/
            autostart/                   # <-- optional
            cfg/                         # <-- optional
            README.md
            docker-compose.override.yml
            env-example                  # <-- optional
            meta.yml

meta.yml

---

devilbox_info:
  name: module name
  description: some more detailed description about the module
  author: <author name> or <nick>
  company: <company name if desired>
  contributors: ["user1", "user2"]
  min_devilbox_version: v1.0.1
  tags:
    - database
    - nosql
    - mongodb

name, description, author and min_devilbox_version should be mandatory.

Considerations

One thing I am not too sure about is if those flames should reside in the users GitHub repositories
or if they should be integrated in a single Devilbox/flames repository and filled up via pull requests.

The first one allows for module voting via GitHub stars and the latter ensure consistency and a central place to find them all.

3

One question about directory structure.
What should be values of user and service ?

About git repositories, i’ve a preference for a central devilbox repo filled by pull request.

Thanks @cytopia for your feedback.

4

User would be something like llaville or cytopia and <service> (or maybe <project>) would be to group all contributions under that username.

This would then allow to have the same project/service submitted by different users with most likely different flavours.

Let’s assume I submit a project/service named kafka with a couple of options. Then you also submit one, but with totally different configuration and goals in mind. Having both submitted under our corresponding usernames would allow for two different kafka projects to be available and choose from.

Let’s see them side by side

1. Per user submission

README.md
flames/
    cytopia/
        kafka/
            autostart/                   # <-- optional
            cfg/                         # <-- optional
            README.md
            docker-compose.override.yml
            env-example                  # <-- optional
            meta.yml
    llaville/
        kafka/
            autostart/                   # <-- optional
            cfg/                         # <-- optional
            README.md
            docker-compose.override.yml
            env-example                  # <-- optional
            meta.yml

Pro’s

  • More variety
  • More individual submissions

Con’s

  • Harder choice, which is actually the better project
  • More confusion
  • Harder to maintain

2. Single submission

README.md
flames/
    kafka/
        autostart/                   # <-- optional
        cfg/                         # <-- optional
        README.md
        docker-compose.override.yml
        env-example                  # <-- optional
        meta.yml

Pro’s

  • Easier choice, which is actually the better project
  • Less confusion
  • Easier to maintain

Con’s

  • Less variety
  • Less individual submissions

Break-down

Absolutely not sure yet, which should be the way to go and after writing it down I am actually more in favour of the Single submission

Any more thoughts on this?

5

@llaville

After some more thoughts on this I think the single submission will allow for more quality and easier maintenance. If there are no real objections against it, we should use it as a way to move forward.

Repository is available (though pretty empty atm)

If you have something, feel free to make a first PR and we see how it goes from there.

2 Likes
6

@cytopia Agree with you on single submission format

About my first proposals (teasers), here are what contributions i’ve in minds (links to docker hub):

Ready to be proposed

Almost Ready to be proposed, a full TICK Stack

Tell me, what subject you want first !

7

I would go with Docker. The Docker image has frequent updates and the GitHub project seems quite big. It also has some env variables.

So by getting the first project up and running we can probably already see further pro’s and con’s of the chosen directory structure design.

Additionally I can work out CI tests once there’s at least one of them in there.

8

Ok for Selenium. I will propose a first PR in the next days. Deadline should be May 1st.

1 Like
9

@llaville I just found the official Docker Selenium repository and it would be worth considering it as well:

10

@cytopia I know that this image exists.
Do you read the note at https://github.com/elgalu/docker-selenium#official-repo about differences ?

BTW, I’ve begin to prepare the PR, and should be proposed in next hours !

11

@llaville :+1:
Already started to look into your PR and will give you a more detailed feedback on it at the PR.

1 Like