Setup simplification
We could avoid asking the user to run any script to setup the local instance of the GGI Board.
Cons first:
- we would not be able to automatically inject the link to the static website in the "forked" repo
Readme.md
file.- unless we provide a more powerful token and commit inside the CI Job, but I dislike the idea
- but we might (?) (see #17 (closed)) be able to update its description.
- I think that's all, but maybe i missed something
Pros:
- the user doe not have to clone the repo locally
- does not have to configure the
conf/ggi_deployment.json
file - does not have to install Python and run script
- the repo itself remains closer to upstream repo, easing updates.
Idea:
The GitLab-CI Job has access to required data through default variable:
CI_SERVER_URL=https://gitlab.com
CI_PROJECT_PATH=NicolasToussaint/my-ggi-board
CI_PROJECT_URL=https://gitlab.com/NicolasToussaint/my-ggi-board
We also have a pointer to the generated website: CI_PAGES_URL=https://nicolastoussaint.gitlab.io/my-ggi-board
The idea would be to include a new "Initialisation" step in the CI script that would call the ggi_update_website.py
script only once.
- question: how to detect the CI script is being run for the first time ?
- answer: I don't know. Maybe check the presence of labels & Activities Issues
Bonus: It would make it very easy to configure an initial "Well done !" page in the static website, that we would be displayed after subsequent calls to CI script