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

✨ [#1910] Add first NL-DesignSystem components #909

Merged
merged 6 commits into from
Jan 15, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,8 @@ jobs:

steps:
- uses: actions/checkout@v3
with:
submodules: 'true'
- name: Set up backend environment
uses: maykinmedia/setup-django-backend@v1
with:
Expand Down Expand Up @@ -111,6 +113,8 @@ jobs:

steps:
- uses: actions/checkout@v3
with:
submodules: 'true'
- name: Set up backend environment
uses: maykinmedia/setup-django-backend@v1
with:
Expand Down Expand Up @@ -155,6 +159,8 @@ jobs:

steps:
- uses: actions/checkout@v2
with:
submodules: 'true'

- name: Set tag
id: vars
Expand Down
10 changes: 10 additions & 0 deletions .github/workflows/code-quality.yml
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,8 @@ jobs:
sudo apt-get update
sudo apt-get install -y libxml2-dev libxmlsec1-dev libxmlsec1-openssl
- uses: actions/checkout@v2
with:
submodules: 'true'
- uses: actions/setup-python@v2
with:
python-version: '3.9'
Expand All @@ -40,6 +42,8 @@ jobs:
sudo apt-get update
sudo apt-get install -y libxml2-dev libxmlsec1-dev libxmlsec1-openssl
- uses: actions/checkout@v2
with:
submodules: 'true'
- uses: actions/setup-python@v2
with:
python-version: '3.9'
Expand Down Expand Up @@ -67,6 +71,8 @@ jobs:

steps:
- uses: actions/checkout@v3
with:
submodules: 'true'
- uses: actions/setup-python@v4
with:
python-version: '3.9'
Expand Down Expand Up @@ -97,6 +103,8 @@ jobs:
steps:
- name: Checkout
uses: actions/checkout@v2
with:
submodules: 'true'
- name: Install dependencies
run: |
npm install --legacy-peer-deps
Expand All @@ -113,6 +121,8 @@ jobs:
sudo apt-get update
sudo apt-get install -y libxml2-dev libxmlsec1-dev libxmlsec1-openssl
- uses: actions/checkout@v2
with:
submodules: 'true'
- uses: actions/setup-python@v2
with:
python-version: '3.9'
Expand Down
8 changes: 5 additions & 3 deletions .github/workflows/codeql-analysis.yml
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,8 @@ jobs:
steps:
- name: Checkout repository
uses: actions/checkout@v3
with:
submodules: 'true'

# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
Expand All @@ -48,11 +50,11 @@ jobs:
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.

# Details on CodeQL's query packs refer to : https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality


# Autobuild attempts to build any compiled languages (C/C++, C#, or Java).
# If this step fails, then you should remove it and run the build manually (see below)
- name: Autobuild
Expand All @@ -61,7 +63,7 @@ jobs:
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun

# If the Autobuild fails above, remove it and uncomment the following three lines.
# If the Autobuild fails above, remove it and uncomment the following three lines.
# modify them (or add more) to build your code if your project, please refer to the EXAMPLE below for guidance.

# - run: |
Expand Down
4 changes: 4 additions & 0 deletions .github/workflows/dependencies.yml
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,8 @@ jobs:

steps:
- uses: actions/checkout@v2
with:
submodules: 'true'
- uses: actions/setup-python@v2
with:
python-version: '3.9'
Expand All @@ -43,6 +45,8 @@ jobs:

steps:
- uses: actions/checkout@v2
with:
submodules: 'true'
- uses: actions/setup-python@v2
with:
python-version: '3.9'
Expand Down
6 changes: 3 additions & 3 deletions .gitmodules
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
[submodule "deployment/maykin-deployment"]
path = deployment/maykin-deployment
url = git@bitbucket.org:maykinmedia/maykin-deployment.git
[submodule "open-inwoner-design-tokens"]
path = open-inwoner-design-tokens
url = git@github.com:maykinmedia/open-inwoner-design-tokens.git
3 changes: 3 additions & 0 deletions Dockerfile
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,9 @@ WORKDIR /app
COPY ./build /app/build/
COPY ./*.json ./*.js ./.babelrc /app/

# Clone design token submodule (normally done using git submodule update --init)
RUN git clone https://github.com/maykinmedia/open-inwoner-design-tokens.git
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how often this repo will be updated, but I think it would be a good idea to pin this to a specific tag. Otherwise every pipeline of Open Inwoner will always pull in the master branch of the package's repo.

We could probably do something like this: https://stackoverflow.com/a/21699307 (also makes us skip any history, since we're not going to use that in the image anyway)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just created a Tag (v0.0.1) but I wonder: if this will actually still be updated a lot, isn't it better to keep on pulling the Main branch - in these beginning stages? Every commit means a new Tag since they are big changes every time (I think).
In a far(?) future that repo could become the single source of truth (when they will also be used by the designers).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already had to update it to version 0.0.2... :-D

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could let it point to the main branch if it will be modified a lot, though I am generally wary of not pinning these kinds of dependencies, because I like to know what versions of dependencies I have for a specific image and not have potential unwanted changes be included automatically. If @alextreme approves to use master then it's fine by me.

You could add --depth 1 to git clone to avoid pulling in the history (https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---depthltdepthgt)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already turned it into this "RUN git clone --depth 1 --branch 0.0.2 https://github.com/maykinmedia/open-inwoner-design-tokens.git" with the tag, but how will we remember the Tag needs to be updated too? Add to both repo's documentations?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's indeed quite a chore to keep these kinds of relations in-sync between repositories, this is why for maykin-deployment I also avoid pinning to a specific branch (and why I'd prefer to go for a single combined repo, this would avoid the problem altogether).

For now I approve and prefer pulling from main/master instead of a release-branch. I'll set a reminder to re-evaluate this in half a year, if changes have become incidental then we'll pin this again to a release-branch

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stevenbal @alextreme So should I remove the clone-from-Tag thing and revert to what it was?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes


# install WITH dev tooling
RUN npm ci --legacy-peer-deps

Expand Down
93 changes: 53 additions & 40 deletions INSTALL.rst
Original file line number Diff line number Diff line change
Expand Up @@ -58,8 +58,14 @@ development machine.

.. code-block:: bash

$ git clone git@github.com:maykinmedia/open-inwoner.git
$ cd open-inwoner
git clone git@github.com:maykinmedia/open-inwoner.git
cd open-inwoner
# initialize submodules
git submodule update --init --recursive

This will include the `Open-Inwoner-Design-Tokens`_ subdirectory. When all is built and run this is where the OIP design tokens CSS will be generated. When this repository gets updated, it needs to be pulled again.

.. _Open-Inwoner-Design-Tokens: https://github.com/maykinmedia/open-inwoner-design-tokens

3. Install all required (backend) libraries.
**Tip:** You can use the ``bootstrap.py`` script to install the requirements
Expand All @@ -68,52 +74,59 @@ development machine.

.. code-block:: bash

$ virtualenv env
$ source env/bin/activate
$ pip install -r requirements/dev.txt
virtualenv env
source env/bin/activate
pip install -r requirements/dev.txt

4. Run third-party install commands:

- Install the required browsers for `Playwright`_ end-to-end testing.

.. code-block:: bash

$ playwright install
playwright install

.. _Playwright: https://playwright.dev/python/

5. Install and build the frontend libraries:

.. code-block:: bash

$ npm install
or as an alternative: npm ci --legacy-peer-deps
$ npm run build
npm install
npm run build

- Or as an alternative:

.. code-block:: bash

npm ci --legacy-peer-deps
npm run build

6. Create the statics and database:

.. code-block:: bash

$ python src/manage.py collectstatic --link
$ python src/manage.py migrate
python src/manage.py collectstatic --link
python src/manage.py migrate

7. Create a superuser to access the management interface:

.. code-block:: bash

$ python src/manage.py createsuperuser
python src/manage.py createsuperuser

8. You can now run your installation and point your browser to the address
given by this command:

.. code-block:: bash

$ python src/manage.py runserver
python src/manage.py runserver

9. Create a .env file with database settings. See dotenv.example for an example.

$ cp dotenv.example .env
.. code-block:: bash

cp dotenv.example .env

**Note:** If you are making local, machine specific, changes, add them to
``src/open_inwoner/conf/local.py``. You can base this file on the
Expand All @@ -133,13 +146,13 @@ ElasticSearch

.. code-block:: bash

$ bin/start_elasticsearch.sh
bin/start_elasticsearch.sh

2. Then build the indices:

.. code-block:: bash

$ src/manage.py search_index --rebuild
src/manage.py search_index --rebuild


Update installation
Expand All @@ -151,31 +164,31 @@ When updating an existing installation:

.. code-block:: bash

$ cd open-inwoner
$ source env/bin/activate
cd open-inwoner
source env/bin/activate

2. Update the code and libraries:

.. code-block:: bash

$ git pull
$ pip install -r requirements/dev.txt
$ npm install
git pull
pip install -r requirements/dev.txt
npm install
or as an alternative: npm ci --legacy-peer-deps
$ npm run build
npm run build

3. Update the statics and database:

.. code-block:: bash

$ python src/manage.py collectstatic --link
$ python src/manage.py migrate
python src/manage.py collectstatic --link
python src/manage.py migrate

4. Update the ElasticSearch indices:

.. code-block:: bash

$ src/manage.py search_index --rebuild
src/manage.py search_index --rebuild


Testsuite
Expand All @@ -185,7 +198,7 @@ To run the test suite:

.. code-block:: bash

$ python src/manage.py test open_inwoner
python src/manage.py test open_inwoner

Configuration via environment variables
---------------------------------------
Expand Down Expand Up @@ -223,17 +236,17 @@ The easiest way to get the project started is by using `Docker Compose`_.

.. code-block:: bash

$ git clone git@bitbucket.org:maykinmedia/open-inwoner.git
git clone git@bitbucket.org:maykinmedia/open-inwoner.git
Cloning into 'open-inwoner'...
...

$ cd open-inwoner
cd open-inwoner

2. Start the database and web services:

.. code-block:: bash

$ docker-compose up -d
docker-compose up -d
Starting open-inwoner_db_1 ... done
Starting open-inwoner_web_1 ... done

Expand All @@ -243,14 +256,14 @@ The easiest way to get the project started is by using `Docker Compose`_.

.. code-block:: bash

$ docker logs -f open-inwoner_web_1
docker logs -f open-inwoner_web_1

3. Create an admin user. If different container names are shown above, use
the container name ending with ``_web_1``:

.. code-block:: bash

$ docker exec -it open-inwoner_web_1 /app/src/manage.py createsuperuser
docker exec -it open-inwoner_web_1 /app/src/manage.py createsuperuser
E-mail address: admin@admin.com
...
Superuser created successfully.
Expand All @@ -266,7 +279,7 @@ The easiest way to get the project started is by using `Docker Compose`_.

.. code-block:: bash

$ docker-machine ls
docker-machine ls
NAME ACTIVE DRIVER STATE URL
default * virtualbox Running tcp://<ip>:<port>

Expand All @@ -287,16 +300,16 @@ all settings.

.. code-block:: bash

$ docker build -t open_inwoner
$ docker run \
docker build -t open_inwoner
docker run \
-p 8000:8000 \
-e DATABASE_USERNAME=... \
-e DATABASE_PASSWORD=... \
-e DATABASE_HOST=... \
--name open_inwoner \
open_inwoner

$ docker exec -it open_inwoner /app/src/manage.py createsuperuser
docker exec -it open_inwoner /app/src/manage.py createsuperuser

Staging and production
======================
Expand All @@ -309,21 +322,21 @@ the target machine has a clean `Debian`_ installation.

.. code-block:: bash

$ pip install ansible
pip install ansible

2. Navigate to the project directory, and install the Maykin deployment
submodule if you haven't already:

.. code-block:: bash

$ git submodule update --init
git submodule update --init

3. Run the Ansible playbook to provision a clean Debian machine:

.. code-block:: bash

$ cd deployment
$ ansible-playbook <test/staging/production>.yml
cd deployment
ansible-playbook <test/staging/production>.yml

For more information, see the ``README`` file in the deployment directory.

Expand All @@ -346,7 +359,7 @@ Commands can be executed using:

.. code-block:: bash

$ python src/manage.py <command>
python src/manage.py <command>

There are no specific commands for the project. See
`Django framework commands`_ for all default commands, or type
Expand Down
1 change: 1 addition & 0 deletions open-inwoner-design-tokens
Loading