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

Github based Theme Release System #370

Open
manikmagar opened this issue May 21, 2017 · 15 comments
Open

Github based Theme Release System #370

manikmagar opened this issue May 21, 2017 · 15 comments
Milestone

Comments

@manikmagar
Copy link
Member

Based on the template release system described here - https://groups.google.com/d/msg/jbake-user/eQNZYsk8aKM/0Uw-QJTTCAAJ

Here is a tool to initiate jbake site from github managed templates -
https://github.com/manikmagar/jbake-ts

@ancho
Copy link
Member

ancho commented May 22, 2017

👍 That's nice. I just flew over the code. But that's a nice PoC. How about using repository topics to locate template project repositories on github to generate a list of available template projects?

We could use a topic like jbake-template-project.

@manikmagar
Copy link
Member Author

Thanks.

I was thinking about repository topics and search (for this and something else that is not related to jbake), it is good to explore and automate. The thing I did not like is, we cannot really control on what is then getting pulled into our system. With controlled source, we know what is being included. Imagine that topic appearing on wrong repositories that are not really jbake templates and thus results in broken or corrupted template downloads. That would give a bad impression to users, appearing that system is not stable and clean.

If template providers can send a pull request to get their repo added to a controlled source, eg. http://jbake.org/templates/providers.json, then we can easily read this to show list of available repositories (jbake-ts -a).

@ancho
Copy link
Member

ancho commented May 22, 2017

Hmm...maybe you are right. That depends on what a controlled source is and who controls it. Currently there are some checks if common folders are present defined by the configuration. But you are right it's probably not the best idea to trust every repository with a tag on it.
We could collect them within the organization for example and run tests against them, before adding them to the list or something like that.

I wrote a functional test for the current built in template projects to check if they are compatible with the current application.
Something like that could be used to read the (maybe generated) json file or what ever and validate them further.

All in all both should be possible. Reading from a curated list of "trusted" templates and using self published template projects.

@manikmagar
Copy link
Member Author

👍 testing/validating the templates is good. Similar thing can be used in download step, i.e. once requested template is installed jbake-ts -t {reponame} {version} then run it through basic structure validations.

@ancho
Copy link
Member

ancho commented May 22, 2017

jbake does that already. I also wrote a JbakeConfigurationInspector as a side effect of #341 which could be extended and reused during the initialization phase.

@manikmagar
Copy link
Member Author

👍 That is nice.
Hope to have more templates available for baking :)

@jonbullock
Copy link
Member

Ah, I sent my e-mail last night before I noticed this issue had already been raised - thanks @manikmagar for already doing this :)

The way I thought it could work last night was the initial list of available example projects (say if you run -i without any params) for the CLI (and maybe build plugins jbake-org/jbake-gradle-plugin#30) should come from a trusted source (i.e. a json file on jbake.org) but that the end user could still override and specify a custom source (using the suggested format), then it's up to them to trust the source. Third parties can still have their repo added to the master list by submitting a PR.

@jonbullock jonbullock added this to the v2.7.0 milestone May 24, 2017
@manikmagar
Copy link
Member Author

Np, welcome :).

I agree, there should be a way to pull from custom source either from a CLI or just download the zip from any custom repo and unzip it to begin (jbake -i may not be needed). Do you think it should be part of jbake core or a separate module? I think, may be implementation could be a sub-module but can share the same CLI .

@ancho
Copy link
Member

ancho commented May 24, 2017

There is an open issue #274 for splitting into core and application module. I think it would be a good idea to do so and integrate your implementation into core using it in the cli module, or what ever it is called then. That way we would be able to reuse it in the gradle plugin to implement an initialization task without the dependency to the cli and jetty stuff. See jbake-org/jbake-gradle-plugin#30

I can do the splitting....

@jonbullock
Copy link
Member

Sounds logical to me to have the fundamental functionality in the core of JBake that the CLI sub-module can use as well as the build tool plugins.

@jonbullock
Copy link
Member

Linking to another site template: https://github.com/SiddheshRane/jbake-clean-blog-template

I think a standard term needs to be agreed upon for these... template seems confusing as it's also used to describe files within these projects...

@manikmagar
Copy link
Member Author

Agree! How about a traditional popular term 'theme'?

@jonbullock
Copy link
Member

Yeah seems to be term of choice so lets go with it.

@manikmagar
Copy link
Member Author

I searched for jbake template. Very few templates i see are using tags like jbake-template-project. Another option is to search by the presence of "jbake.properties" in repository but that doesn't guarantee that repo is a template and not someone's site. Unless, repo is created as a template repostiory.

@manikmagar
Copy link
Member Author

@jonbullock had this jbake-org/jbake.org#64 to create template showcase. Maybe that is first step to get template visibility?

@jonbullock jonbullock modified the milestones: v2.7.0, v2.8.0 May 25, 2021
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