Skip to content
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

Private Forge List #18

Open
cdenneen opened this issue Jun 15, 2015 · 6 comments
Open

Private Forge List #18

cdenneen opened this issue Jun 15, 2015 · 6 comments

Comments

@cdenneen
Copy link

When you load the internal forge URL there is nothing but search page.
Is there anyway for it to list all the internal modules published?

Also another idea might be (along lines of Puppet Supported and Puppet Approved) is allowing same sort of right rail for "Internal Approved". So when using in an internal corporate sense as you want to get more people to start using puppet (so it's not just the operations team) you provide list of approved modules that you might recommend (instead of finding ANY module on the forge)... so for example if you determine you want everyone to use opentable/iis instead of simondean/iis you can make that approved module list something that shows on the internal forge. (Maybe having the same list of externally Puppet Supported and Approved module right rail boxes is good to so it always stays up to date with what's supported)..

(so i guess that might be considered 3 feature requests)

@i11
Copy link
Contributor

i11 commented Jun 17, 2015

Cool! Thanks a lot for the input!

I'm not entirely sure about doing any calls at the start page. It might become rather costly resource wise as it would be tight to the same API requests, that for example result md5 calculations. We could add a checkbox for searching only through hosted modules, so that a search with an empty string and that checkbox ticked give the result you want. Otherwise it might get ugly without introducing the persistence and caching. Of course depending on your use case your modules might be already in the memory stored as file cache, so it could go rather smooth. Just thoughts from the top of my head...

I'm trying to avoid persistence as much as I can. I know it's inevitable in the end, but I would rather postpone the introduction of it. That said any sort of approvals, markings etc require some sort of a DB... However we could have a tag for hosted and maybe proxy cached modules, so it would be easy to spot them in the search result and in a way cover your first FR.

Please let me now your thoughts on this.

Also I've tried to make the web UI part plugable, so it's actually possible to render any page you want using haml (see https://github.com/unibet/puppet-forge-server#web-ui)

@danjng
Copy link

danjng commented Jul 21, 2015

So, querying with a '*' works to get a full list. That used to work for me, but after some time being up, it no longer works.

I am looking into some root cause...

@i11
Copy link
Contributor

i11 commented Jul 21, 2015

Hi,

Could you please also create a separate issue for it so we wouldn't hijack this one.
Please mention if you see anything in the logs. It would be interesting to see if restart helps, but that could be the last step. strace and gdb might show something useful.

@danjng
Copy link

danjng commented Aug 24, 2015

Just chiming in on this thread again. I am not sure if any changes in that area had been made to the gem, but searching for '*' seems to work again, consistently and without any issues on the latest version.

Regarding OP's "Internal Approved" idea, I wonder if that's something we can add to metadata.json without it interfering with other stuff that might depend on that info? Onto the list of things to think about... :)

@i11
Copy link
Contributor

i11 commented Sep 2, 2015

1960149 tags modules served by directory backend (not cache)

I'd guess you could add extra fields in the metadata even though puppet lint might complain about it.

@i11
Copy link
Contributor

i11 commented Sep 2, 2015

released 1.8.0 with private tagging for hosted modules

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants