1. Marcin Kuzminski
  2. RhodeCode
  3. Issues


Issue #57 new

Allow templates access to the repo config file

Matt Turk
created an issue

It might be nice to expose the entire set of settings in the repository's hgrc to the template engine. This way supplemental information could be added, for instance a license, or a URL to a screenshot. It might also be nice to have the option to display the README file from the current tip.

Comments (10)

  1. Marcin Kuzminski repo owner

    If i understand correctly You are talking about editing repository's hgrc files via web interface ? In general i'd rather not to do that. It raises serious security risks, image some create a hook that does some deletions after push how we can verify what's good and whats bad ?

    Also the hgrc files are not pulled during a clone or pull so it's just a local storage. All options in rhodecode are kept in database, together with some db stored global hgrc that's in control some of the rhodecode options.

    "This way supplemental information could be added, for instance a license, or a URL to a screenshot. It might also be nice to have the option to display the README file from the current tip." - I don't see a problem of implementing it in other way than in hgrc files. For example i like the README option, don't know where to put this in the web bug in general idea is worth implementing.

    If i got Your post wrong pleas let me know.

  2. Matt Turk reporter

    Ah, you're right -- it doesn't need to be implemented in the hgrc. I'm just coming from the hgwebdir mindset, where we extended our templates to give this information to the user, rather than having them stored separately. (All information was only editable from the command line, though -- strictly read only from the web interface, which was perfectly fine.) Having supplemental information hanging off the model itself would be just as good, if not better!

    In lieu of actually adding every possible field, is it possible to have an example of adding a new attribute/field to the model added to the docs?

  3. Marcin Kuzminski repo owner

    Is it possible to post get a screenshot how did You put the info to the templates ? it'll give me a general idea of what exactly we're talking about.

    And getting back to the extending the information stored for repository. Extending the database Models is very simple in that case, Displaying information also, since it's just getting extra variables from already given objects. The real issue here is to write the code responsible for insertion and validation i.e. creating forms, validators and models.

    Maybe to start, what extra fields are we talking about ? License, url, logo ?

  4. Matt Turk reporter

    Sure, I've attached a screenshot of the top-level view, selecting from a single repository. These repos are visible at barn.enzotools.org.

    The fields we'd currently been using were screenshot (just a URL, though, not an attachment), license, level-of-support and then we had it insert the contents of the tip's top level README file.

  5. Marcin Kuzminski repo owner

    Hi, I like the general idea of that ! I see no problems of extending the information kept in repository db. The perfect solution would be extendable/customizable fields, that You can add to each repository. You need license You add this field to given repository. of course they wouldn't be validated but that's the price of extendibility

    Another smaller problem is with the screenshot/logo I see no place where I could put that in html.

  6. Matt Turk reporter

    I think screenshots are something we used to have that maybe we don't need anymore. If all else fails, one could imagine just having optional HTML rendering of the description, which could include the IMG tag. BUt either way, being able to set custom variables would be really awesome.

  7. Sean Russell

    We'd like to be able to auto-connect newly created repositories (or clones) to Hudson instances; this requires a change to the per-repository hgrc file. Some sort of templating mechanism would be useful for doing things like this without exposing the security risk of allowing users to directly edit the hgrc file.

    For example, we'd like this to be added to every repository created:

      changegroup.hudson = curl http://HHHHHHHHHHH.net/hudson/job/PROJECT/build?delay=0sec 

    where PROJECT is the name of the created repo.

  8. Marcin Kuzminski repo owner

    This can be really made in several ways in rhodecode, there are 3 main hooks connected to rhodecode. the push hooks have a repo name available inside, to You can just put some code in there to run additional informations

  9. Log in to comment