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

Transitioning to Jekyll #11

Open
arguiot opened this issue Jun 30, 2020 · 3 comments
Open

Transitioning to Jekyll #11

arguiot opened this issue Jun 30, 2020 · 3 comments

Comments

@arguiot
Copy link
Contributor

arguiot commented Jun 30, 2020

Hello 👋,

My friend Luka and I are working on transitioning CTO to Jekyll. This is a lot of work, and we're actively looking for solutions to make this transition as smooth as possible. In order to keep as much original code as possible, we're developing solutions to automate things as much as possible.

Because we don't our system to be overloaded by useless code, we would like to move folders such as the test or template folder outside of the _ctoApps directory. Let us know if this is possible!

Best regards

@itmm
Copy link
Contributor

itmm commented Jul 1, 2020

Hi arguiot,

I believe the problem is deeper: for the server (and for Jekyll) we only need the files that are delivered, e.g. no test and template files. But here in the repository we need the files to build the modules (from the template files) and need all the configuration stuff to build them with gulp, webpack or whatever.

If we remove the directories here, we are no longer able to rebuild the modules if changes occur.

So probably we should go another way and provide one known directory in any module that contains the build module (e.g. build?) and we every deployment system must populate this directory. The content of this directory is commited into this repository.

When you want to recreate the Jekyll Website you only need to pull the current master and copy all files in the build subdirectories.

Is that a feasable way for you? If we agree on this way, we have to walk through all the modules and try to provide a proper directory structure. That is a lot of work, but if it moves us forward, it may be worth it.

Kind regards

@arguiot arguiot changed the title Move unnecessary code elsewhere Transitioning to Jekyll Jul 1, 2020
@arguiot
Copy link
Contributor Author

arguiot commented Jul 1, 2020

Hello @itmm,

I renamed the issue so there is more evidence that it's about the transition to Jekyll.

The solution we're working on is similar to what you're describing: we're currently cloning this repo and running Gulp wherever there is a gulpfile.js. Currently, some apps are failing to build. You can find here the .travis.yml and the build logs (the logs are colored, so use cat to view it).

One solution that would really help us would be to provide the pre-built version of the CTO apps. I let you decide the best/easiest option, but in my opinion, having Travis run and deploy the result in another branch. We only need to make sure that the build branch only contains the "useful" code. This would ensure the code is built correctly.

I would also need some apps to be cleaned. For example, the code of adfgvx - index.html should be rewritten to only contain what's in the body tag. Everything else must be moved to cto.config.json. I'm not sure how many apps are impacted by this problem, but if there's only a few, I think I can manage to fix this by opening a pull request.

For the moment, my focus is on making things work, even approximately, so I can begin testing and asking other members of the team how can the experience can be improved.

Looking forward to working with you and other contributors to make this transition as smooth as possible!

Best regards,

@arguiot
Copy link
Contributor Author

arguiot commented Jul 18, 2020

@itmm Any updates? I've been talking to Mr Rech recently on how we can do that. According to him:

I think it might make sense to add version information for npm and node in a structured way into each app.
As an alternative, all apps could be converted to the same version, but maybe that is too much maintenance effort.

So I wanted to have your opinion on my proposal and if you had any ideas on how to make the transition.

Best regards,
Arthur Guiot

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

No branches or pull requests

2 participants