I don't know if it's something that has been already discussed, but I think that having a version inside templates would be useful.

 

This would allow addition of mechanisms to inform users about updates developers are doing to their templates.  For example, if a new parameter is added to a template, all users that have already installed the Docker application won't have it and won't be aware of it.

 

A simple mechanism would be to add version checks in the Fix Common Problems plugin.  In case of version mismatch, one of the recommendation could be to re-install the container using default settings.

 

I see benefits in the following situations:

• A fix has been made to the template.  For example, fixing a bad default permission of a volume.  If users are not aware that a new template fixes some issues, they will have to look at the support thread.  The same questions/problems are more likely to be reported by multiple users.
• A new feature has been added.  This feature may required the usage of a new environment variable.  Unless the container documentation (if any) is read, users are not aware of this new parameter.

 

49 minutes ago, Djoss said:

I don't know if it's something that has been already discussed, but I think that having a version inside templates would be useful.

 

This would allow addition of mechanisms to inform users about updates developers are doing to their templates.  For example, if a new parameter is added to a template, all users that have already installed the Docker application won't have it and won't be aware of it.

 

A simple mechanism would be to add version checks in the Fix Common Problems plugin.  In case of version mismatch, one of the recommendation could be to re-install the container using default settings.

 

I see benefits in the following situations:

• A fix has been made to the template.  For example, fixing a bad default permission of a volume.  If users are not aware that a new template fixes some issues, they will have to look at the support thread.  The same questions/problems are more likely to be reported by multiple users.
• A new feature has been added.  This feature may required the usage of a new environment variable.  Unless the container documentation (if any) is read, users are not aware of this new parameter.

 

Good idea, but needs an overhaul of dockerMan to accomplish.

 

dockerMan when saving the my* templates does not save any tags that are not basically already present in the template presented to the user (it does add one or two extra though like date-added / installed).  eg: if you compare the templates that are stored in /var/lib/docker/unraid/community-templates (which is what CA passes), they have far more tags present than what is saved post install in /boot/config/plugins/dockerMan/templates-user.

 

Personally, I would like every tag that is passed through to dockerMan at install to be saved with the user-template.  (If only for future possible additions to dockerMan)

 

Although not exactly what you're talking about, CA does have a "branch" feature which allows a single template to completely modify itself (what is passed to dockerMan) according to user input.  ( ie: if binhex implemented it, he could have a single sabnzbd that would either install the regular version or the vpn version, and the appropriate environment variables, repository, etc would all be populated accordingly), but that only works during installation.

 

Net result though is that because of this, FCP has zero clue about any extra tags to designate this because of how dockerMan operates.

I had a quick look to dockerMan code and it seems relatively simple to add a new XML field to the saved template.  I guess I can try to contribute by sending a pull request... 

 

8 hours ago, Squid said:

Personally, I would like every tag that is passed through to dockerMan at install to be saved with the user-template.  (If only for future possible additions to dockerMan)

Is it something that someone already tried to push?  Are there any objections against that?

3 hours ago, Djoss said:

Is it something that someone already tried to push?

Not to my knowledge

 

I just discovered that the TemplateURL field is used to update the template...  So a couple of scenarios are covered by this functionality.

This is an old thread but my searching did not yield other threads that are relevant.  

 

I have a few dockers in the CA list.  I want to add a few variables to the template for one of them. 

 

Simple enough, I add the variables and commit to github.  I then deleted the docker and attempted to reinstall from CA.  My new variables were missing... Oh wait, it must be installing from a local copy of the template.  So I go into Docker->"Container Add", and then I manually deleted the template.

 

Ok, so now I attempt to install fresh from CA and again my new variables are missing.  If I follow the template URL directly in my browser it shows the most recent version that includes my additions.  What am I missing with respect to updating the template here? 

 

Thanks in advance.

Edited December 24, 20205 yr by kiowa2005
clarity

Nothing.  CA does rescans every 2 hours, and it reflects the templates at that point.