Request for comment/approval

[cbeauchesne]

@brunobesson Here is a target for CI-CD for the new UI.

Objectives are :

• provide an easy way for developers to show their work to community, without hosting their own server, and without a commit on master
• provide an easy way for developers to release, without digging into ssh/docker complexity

This main idea is write travis scripts in order to :

• publish on github pages any branch commited on this repo
• publish on c2c demo server any commit made on master
• publish on c2c prod server a commit flagged as a release on github.

I will try to write those features on this test repo.

Could you give me your opinion/hints/suggestions ?

[brunobesson]

• OK to publish branches on github pages, but do you intend to have à time to live to remove old stuff?
• OK to introduce some CD for demo server, but:

• I would prefer a specific hostname for commits on master and tags (e.g. master.demov6.camptocamp.org and release.demov6.camptocamp.org)
• Do not forget there isn't only the UI on the demo server

• NOK for CD for production. I think we should postpone this for later.
• Don't you thin all the i18n stuff coul be incorporated in the process you propose?

[cbeauchesne]

OK to publish branches on github pages, but do you intend to have à time to live to remove old stuff?

I will see if it's possible to run a travis script on branch deletion. If it's not possible, it means that we'll must delete them with a manual script. BTW, it's not such a big issue to keep old builds : It's only about disk place on github pages. And a new branch with the same name as an old one will erase old build, so no issue for this use case

I would prefer a specific hostname for commits on master and tags (e.g. master.demov6.camptocamp.org and release.demov6.camptocamp.org)

With my proposal, you'll have only "master.demov6.camptocamp.org". Is that really necessary ?

NOK for CD for production. I think we should postpone this for later.

What is your opinion on this? My point is that we have less risk to automate this step, rather than manually accessing with ssh and typing migration lines on a production server (fat-finger, human error on non-trivial bash lines).

Also, having too many SSH authorization on a prod server (Marc, you, Alex, myself...) is not really a good practice.

And finally, last but not least, it will improve stream-lining of dev process. I'm a huge fan on this :)

Don't you thin all the i18n stuff coul be incorporated in the process you propose?

One part of it : When a commit is made on master, send messages to transifex

The second part must be made on a transfix event (and probably done with travis) : When a message is translated in Transifex, clone repo, create a new branch named translation-<lang>,, commit&push, create a PR.