giseldo/neodataset huggingface dataset:
GFM Typescale > Code span > implement

Implement GitLab Flavored Markdown code span styles following the design specs created in https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1048

See parent epic for detailed information about this component.

Figma assets:

- [Documentation markdown - Code span](https://www.figma.com/file/V3HKN83B7rf2T6sseLMrxa/Type-scale---Documentation-Markdown?node-id=909%3A10)
- [Compact markdown - Code span](https://www.figma.com/file/mjAZxHkK95TlQ6L14aNp2M/Type-scale---Compact-Markdown?node-id=862%3A4)

### Implementation guidelines

- The markdown typescale implementation file is in [`src/components/base/markdown/markdown.scss`](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/src/components/base/markdown/markdown.scss#L1)
- Use the following CSS selector to implement these styles: `code`
- This component shares font styling with the [`gl-monospace` class selector](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/src/components/base/markdown/markdown.scss#L121)
- Add compact markdown variation as a child class selector of `.gl-compact-markdown`
- Add a demo of this component in `src/components/base/markdown/markdown_typescale_demo.html`.

Story points: 1.0
Ensure GlSingleStat animates when data is changed

### Problem

With the introduction of `animateOnMount` being `false` for the animated number utility in gitlab-ui, an animation is only triggered on the `GlSingleStat` component when the value prop is changed, after the component has been mounted. 

Our current implementations of `GlSingleStat` conditionally render and remove the component based on the loading states of API requests, which instead of resulting in a simple prop update, results in an entire component remount. This causes the animation to never be triggered. 

### Solution

We can refactor our implementations of `GlSingleStat` from using `v-if` to `v-show`. This will ensure that the component only mounts once and each subsequent update triggers a prop update instead of a component remount. 

### Steps

- Inspect each instance of `GlSingleStat`
- Where updates to data can occur, i.e. filters available etc, replace `v-if` with `v-show`
- Update tests as these will break on `exists`

#### Notes

There are 6 instances of `GlSingleStat` looks like 3 or 4 instances are subject to data changes requiring animation.

Story points: 3.0
Add CSS utility class for setting a min-width of scale * 7 and/or * 8

As part of the cleanup of [this experiment](https://gitlab.com/groups/gitlab-org/-/epics/6300) – specifically [this line from gitlab!61639](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61639/diffs#fb723e851b8926f6532eeed94f1de1874c3221c7_243_250) – we would like to add a utility class for setting the min-width to `32px`, which is `$gl-spacing-scale-7`, and/or another for setting the min-width to `40px`, which is `$gl-spacing-scale-8`.

```scss
.gl-min-w-7 {
  min-width: $gl-spacing-scale-7;
}

.gl-min-w-8 {
  min-width: $gl-spacing-scale-8;
}
```

Story points: 1.0
Add utility CSS class for setting width of $grid-size × 28

As part of the cleanup of [this experiment](https://gitlab.com/groups/gitlab-org/-/epics/6300) – specifically [this line from gitlab!61639](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61639/diffs#fb723e851b8926f6532eeed94f1de1874c3221c7_243_245) – we would like to add a utility class for setting the width to `224px`, which is `$grid-size * 28`.

```scss
$gl-spacing-scale-28: 28 * $grid-size;

.gl-w-28 {
  width: $gl-spacing-scale-28;
}
```

We could also follow another pattern found in the `gitlab-org/gitlab` project’s `utilities.scss` file:

```scss
.gl-w-grid-size-28 {
  width: $grid-size * 28;
}
```

Story points: 1.0
Fix vue/no-deprecated-slot-attribute violation(s) in src/components/charts/tooltip/tooltip.vue

The file [`src/components/charts/tooltip/tooltip.vue`](https://gitlab.com/gitlab-org/gitlab-ui/-/tree/adea5ac1e4513c72153a773621cc495a9bf219cb/src/components/charts/tooltip/tooltip.vue) violates the [recently](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2269) enabled [`vue/no-deprecated-slot-attribute` rule](https://eslint.vuejs.org/rules/no-deprecated-slot-attribute.html#vue-no-deprecated-slot-attribute).

Migrating to the newer slot syntax is a requirement for us to be able to adopt Vue 3.

## What to do

In broad strokes, migrating this component will involve:

1. Updating the template to use the newer slot syntax
1. Fixing tests and/or adding tests in GitLab UI
1. Creating an integration MR with GitLab, and fixing _its_ tests

### Updating the template

This is the easy part! It's usually as simple as one of these example diffs:

```diff
-  <template slot="first">
+  <template #first>
```

```diff
-  <div slot="foo">Slot content</div>
+  <template #foo>
+    <div>Slot content</div>
+  </template>
```

```diff
-  <slot slot="foo" name="foo">Slot default content</slot>
+  <template #foo>
+    <slot name="foo">Slot default content</slot>
+  </template>
```

```diff
-  <slot v-for="slot in Object.keys($slots)" :slot="slot" :name="slot"></slot>
+  <template v-for="slot in Object.keys($slots)" #[slot]>
+    <slot :name="slot"></slot>
+  </template>
```

```diff
-  <slot v-for="slot in Object.keys($scopedSlots)" :slot="slot" :name="slot" slot-scope="scope"></slot>
+  <template v-for="slot in Object.keys($scopedSlots)" #[slot]="scope">
+    <slot :name="slot" v-bind="scope"></slot>
+  </template>
```

Some components will require more work if they have conditional slot rendering.

### Fixing GitLab UI tests

1. If there are no failing tests, verify that the slot content is actually being tested somehow, and write a new test covering this if not.
1. If there are failing tests, fix them!

### Creating an integration MR with GitLab

1. Once your MR for GitLab UI is in good shape, create an [integration MR against GitLab](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/doc/contributing/gitlab_integration_test.md#using-the-remote-development-package) using the `create_integration_branch` manual CI job.
1. Fix any test failures.

Story points: 2.0
Lint all Markdown files with markdownlint

Let's enforce consistent rules for writing documentation in GitLab UI. We recently [setup markdown lint](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2250), but a lot of `.md` files aren't being linted yet.

- [x] Include all `.md` files in the lint script (except for `CHANGELOG.md` which is auto-generated).
- [x] Fix all formatting errors.

Story points: 2.0
Add styles for .gl-button.close in .gl-popover .popover-header

```scss
.gl-popover {
  .popover-header {
    .gl-button.close {
      margin-top: -$gl-spacing-scale-3;
      margin-right: -$gl-spacing-scale-4;
    }
  }
}
```

Used as part of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64540

Story points: 1.0
Follow-up from "feat(echarts): update to echarts@5"

The following discussion from !2185 should be addressed:

- [ ] @leipert started a [discussion](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2185#note_565928329):  (+5 comments)

    > Seems like there is a significant diff on the timelines...

## What's this issue about

Currently the only chart component that sets the options related to a chart's zoom-bar in accordance with the [design specs](https://www.figma.com/file/17NxNEMa7i28Is8sMetO2H/Data-Visualization?node-id=63%3A697) is `GlLineChart`.

https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2185 removes the option that controls this will be removed from the line-chart component.

In order to keep the existing functionality aligned to the design-specs and increase overall consistency, this MR moves the zoom-bar options into the globally shared chart's theme.

### Components affected

* `GlAreaChart`
* `GlBarChart`
* `GlColumnChart`
* `GlDiscreteScatterChart`
* `GlLineChart`
* `GlStackedColumnChart`

| current implementation | design |
| ------ | ------ |
| ![Screen_Shot_2021-06-08_at_1.04.34_PM](/uploads/f8753bbc74725aac10c1d44d92ba9ddd/Screen_Shot_2021-06-08_at_1.04.34_PM.png) | ![Screen_Shot_2021-06-08_at_1.05.53_PM](/uploads/d299f0171c77e8e2b5def3f388fd8a7b/Screen_Shot_2021-06-08_at_1.05.53_PM.png) |

Here's the design spec: https://www.figma.com/file/17NxNEMa7i28Is8sMetO2H/Data-Visualization?node-id=63%3A697

## Steps to reach this chart

1. `yarn storybook` to start a local development server
2. Open the browser 
3. On the left navigation menu, find **Charts** > **Line Chart** > **With zoom and scroll** (or simply visit `?path=/story/charts-line-chart--with-zoom-and-scroll`)

## Implementation plan

1. `src/utils/charts/theme.js` seems to contain a `dataZoom` property. My initial guess is that this property can be used to define a background color for the highlight. You can check the eCharts docs here: https://echarts.apache.org/en/option.html#title

Story points: 2.0
GlAvatar: Identicon fallback inconsistent with GitLab implementation

## What/Why

Found as part of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62419

The classes and colors used for the `identicon` component in GitLab are different than here in GitLab UI.  I am unclear on which is correct so part of this issue if determining **where** to fix this.

GitLab UI does its class calculations in the [avatar.vue](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/src/components/base/avatar/avatar.vue) file. <br />
GitLab does its class calculations in the [avatar_helper.js](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/helpers/avatar_helper.js) file.

## Examples of inconsistencies

**Background color**
- GitLab UI class `.gl-avatar-identicon-bg7` => `#bfbfbf ($gray-200)`
- GitLab class `.identicon.bg7` => `#eee ($identicon-gray)`

**Font color (Single Letter)**
- GitLab UI class `.gl-avatar-identicon` => `#303030 ($gl-text-gray-900)`
- GitLab class `.identicon` => `#525252 ($identicon-text-color)`

## Screenshot

| GitLab | GitLab UI |
| ------ | ------ |
| ![Screen_Shot_2021-06-02_at_11.18.25_AM](/uploads/32cbb46678fdeb28b9a4a0e746aaf161/Screen_Shot_2021-06-02_at_11.18.25_AM.png) | ![Screen_Shot_2021-06-02_at_11.18.38_AM](/uploads/d3620699a198a6429bbdb95994924641/Screen_Shot_2021-06-02_at_11.18.38_AM.png) |

## Proposal

I would like to determine which color set is correct so that we can update the other to match the styles.  There is a huge upside in depending on `GlAvatar` to handle the `identicon` fallback as it really cleans up the template.  However, until we clean up the old usages of `identicon` we want to be sure to keep these color patterns inline as they help users identify their projects/groups at a glance.

cc/ @nickbrandt

Story points: 1.0
GlTable > Set rows primary hover background to match design sytem

This follows up on @cam.x's comment: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62134#note_580549583

In the **Threat Monitoring** app, policy rows' background color on hover should be `#e9f3fc` (`blue-50`).

![](https://gitlab.com/gitlab-org/gitlab/uploads/39a751f0e62ca2d391a9cc140886f912/Frame_1.png)

Let's update `GlTable`'s styles to align with the design system.

Story points: 1.0
GlDrawer's close button should be top-aligned

Currently, `GlDrawer`'s close button is vertically centered in the header. Here's an example of how it looks in **Threat Monitoring**:

![Screen_Shot_2021-05-19_at_3.12.42_PM](/uploads/65ff97cf83486ce37b63c082eedcde7b/Screen_Shot_2021-05-19_at_3.12.42_PM.png)

According to some ~"group::container security" [designs](https://gitlab.com/gitlab-org/gitlab/-/issues/267346/designs/3b_drawer_container.png), and to the [Sketch exports](https://gitlab-org.gitlab.io/gitlab-design/hosted/design-gitlab-specs/drawer-spec-previews/), the close button should be aligned to the top of the header.

![Screen_Shot_2021-05-19_at_3.14.44_PM](/uploads/d76a818836bae81892f2dd4c53385056/Screen_Shot_2021-05-19_at_3.14.44_PM.png)

Let's update `GlDrawer` to match the specs.

Story points: 2.0
Make table sorting options more obvious

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label:

- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

Following on from discussion in https://gitlab.com/gitlab-org/gitlab/-/issues/301082#note_570459360, are there options we can explore to make the table sorting more obvious to users?

> Ahh, I have to click on the Time column for the arrow to display. It wasn't obvious to me that sorting by the Time column 
> was even an option because I didn't see the arrow.
>
> ![Screen_Shot_2021-05-07_at_4.58.57_PM](https://gitlab.com/gitlab-org/gitlab/uploads/a31e914f0d0c17d6f6ed0cfa0494a767/Screen_Shot_2021-05-07_at_4.58.57_PM.png)
> 
> I wonder if there is some way to make this more obvious @ekigbo ?

> This feels familiar like it tripped me up once before in the UI. Ah yes, in the DevOps Adoption table.
> 
> @npost Do we have any other design options for sorting?

### Proposal 

Add blue hover highlighting as described in [@ameliabauerly's comment](https://gitlab.com/gitlab-org/gitlab/-/issues/330464#note_571675576)

Story points: 1.0
Replace Node Sass (node-sass) with Dart Sass (sass) in JavaScript

- [x] [plentycode/sass-export#69](https://github.com/plentycode/sass-export/issues/69)
- [x] ~~!2175: Update sass-export to 2.1.0 to partially migrate to sass~~
- [x] !2846: Update sass-export to 2.0.1 to partially migrate to sass
- [x] !2176: Replace node-sass with sass

Part of &5923

Story points: 32.0
Add pagination to insight-ui

- Bump jwt lifetime to 1 hour (so we have a workaround for pagination/timeout interactions)
- A user can view multiple pages of insight logs
- Resolve differences in api parameters

Frontend sends POST request in the following format

**REQUEST**
```JavaScript
METHOD: POST
Request URL: `https://${insight_log_endpoint}/fetch?page=0&rowsPerPage=10`
Parameters: page=0 & rowsPerPage=10
Request Headers:{
  Content-type: application/json
}
Request Payload:{
  JWT-Base64-token
}

```

**Expected RESPONSE**
```JavaScript
{
  records:[{...},{...}],
  page: 0,
  rowCount: 2
}
```

Story points: 2.0
Add pagination to insight-api (backend)

Frontend sends POST request in the following format

**REQUEST**
```JavaScript
METHOD: POST
Request URL: `https://${insight_log_endpoint}/fetch?page=0&rowsPerPage=10`
Parameters: page=0 & rowsPerPage=10
Request Headers:{
  Content-type: application/json
}
Request Payload:{
  JWT-Base64-token
}
```

**Expected RESPONSE**
```JavaScript
{
  records:[{...},{...}],
  page: 0,
  rowCount: 2,
  rowsPerPage: 10
}
```




Story points: 2.0
Create and use strict TLS configuration in all communication between components

**As a** 
<br>**I want to**
<br>**so that**

**:white\_check\_mark: Acceptance criteria**

1. All components use a secure TLS configuration
1. TLS configuration can be managed in one separate package
1. Link to TLS config from docs

**:hammer\_and\_wrench: Proposed technical solution**

* Create a `common` package that sets the security parameters on a `*tls.Config` to strict values. Only the latest TLS and best ciphers. This only applies to communication between components we build.

**:link: Reference links**

*



Story points: 3.0
Remove sorting in Insight app

![Screenshot_2018-11-23_at_14.18.25](/uploads/0ff1243da92a23938523a16f24d635d5/Screenshot_2018-11-23_at_14.18.25.png)

Sorting of dates appears to be bugged, as 11/7 comes before 11/23 

Remove sorting completely, so that it will have default sorting by date (from backend)

Story points: 1.0
[Investigate] Docker image outway:latest does not work

The latest docker image for the nlx outway does not work. All services have NO inway addresses.

This may be due to the day docker handles `:latest`, could a non-stable push have resulted in this error? Or has `:latest` not properly been tagged for a while? Start checking the CI/CD first and find out which version `:latest` currently is.

$ docker pull nlxio/outway:latest
latest: Pulling from nlxio/outway
Digest: sha256:c28f77c3c50043e96c35ac3ba124bd7b27b086f0e52c806f3e1c048b5b07ecfa

Timebox: 2 uur

Story points: 0.0
Move CDN dependencies into local projects

Move CDN dependencies into a projects (like bootstrap, jquery and others)
In general, CDN is used in non-react projects.

NLX Certportal (on test): https://certportal.test.nlx.io/
![image](/uploads/ec0e1a0609da8b34f7272677473696f5/image.png)

Haarlem Parkeervegunning: https://application.test.haarlem.commonground.nl/
![image](/uploads/3414e56cc5eb79f42161584c8463568a/image.png)

NLX Docs https://docs.test.nlx.io/
![image](/uploads/a0ba5ae23f18204569bfa01fb85b477b/image.png)

Story points: 1.0
Create a solid plan/stories for implementing autorisation

As a PO
I want to have a clear plan for implementing autorisation
so that can present NLX as a good solution for organizations that need authorisation

Acceptance criteria, for example:
- Clear technical plan for implementation
- Necessary stories are added and refined and an epic is created

Notes
- Brainstorm / Experiment
- Write story(ies)
- Check with Sergei to prevent unnecessary double work, they just implemented a similar solution in ZDS 2.0 API reference components

Story points: 2.0
Create a common-ui library

As a developer
I want to have a common ui library
so that I can reuse components in multiple frontends

Acceptance criteria, for example:
- There is a common ui package
- All currently required components are available in the common ui package
- Stories are created on the backlog for all parts that are not part of this story

Notes
- This story is not concerned with actually replacing the components in the interfaces with the common ui components.
- But stories should be created for what needs to be done later.
- Relative imports
- Imports through an own npm namespace `@nlx/common-ui` and use [npm link](https://docs.npmjs.com/cli/link)

Story points: 3.0
Setup initial NLX performance benchmarking

Benchmarking number of requests per second, find the boundaries for becoming io-bound, cpu-bound, memory-bound, on several systems.

Ideal would be to integrate those tests in deployment pipeline.

This user story replaces #27, more precise the following aspect:
Performance and scalability benchmarks. E.g. number of requests per second NLX can perform on a certain system.


DoD:

1. Create `nlx-bench` repo for the following:
1. Create server application to serve predictable-duration responses. w/ ansible script to deploy
1. Setup ansible scripts for inway/outway on servers. Use acc NLX network.
1. Create client application which measures round-trip time. w/ ansible script to deploy
1. Let client write output to files, no need for public dashboard / automation.

Proposed tech solutions:

vegeta or apache benchmark
https://github.com/tsenart/vegeta


Story points: 8.0
Add NLX preprod and prod environment to current cluster and CI

**As a customer** 
<br>**I want to use the NLX production environment**
<br>**so that I can have confidence in the stability of my solution that makes use of NLX**


**:white\_check\_mark: Acceptance criteria**

1. Note:  MVP production environment means a "best effort" production environment reserved for specific partners
1. Pre-prod: New customers show that they are ready to join production
   <br>Prod: New customers that succeed in pre-prod run their business in this NLX network
1. Those environments should have a secure process to provide certificates to organisations, with a manual verification step (see #317)
1. pre-prod and production environment should always be at same version.
1. demo environment needs to stay close to pre-prod and prod but intended deviations should be possible.
1. directory.nlx.io should show prod directory content.
1. directory.preprod.nlx.io should show pre-prod directory content
   


**:hammer\_and\_wrench: Proposed technical solution**

* Update helm charts
* remove cert portal/cf ssl CA from helm charts
* add gitlab CI jobs to manual trigger pre-prod prod release
* DNS record management

**:link: Reference links**

* 

- Deploy a preprod and prod environment from gitlab CI as manual release (same as demo)

Story points: 5.0
Create onboarding process for preprod and prod environment

**As** a API provider
<br>**I want** to get a certificate for pre-prod and prod environment
<br>**So that** can start using NLX on pre-prod and prod

**:white\_check\_mark: Acceptance criteria**

1.  There is a document describing the process of providing a certificate
2.  Create a new CA and save keys in nlx-pass
3.  Add docs to docs.nlx.io on how to request a certificate

**:hammer\_and\_wrench: Proposed technical solution**

* CF ssl

**:link: Reference links**

* 

Story points: 3.0
Setup link checker for docs in CI

As a **manitainer**
<br>I want to **automatically check if all used URLs in docs are still valid when committing**
<br>so that **we prevent dead links and solve them as quickly as possible when they happen anyway**


**:white\_check\_mark: Acceptance criteria**

1. docs.nlx.io and appstore.commonground.nl/docs
1. build fails when internal links are dead
1. daily job running for link checking (only give warning in ci/cd)

**:hammer\_and\_wrench: Proposed technical solution**

* In the CI: use [muffet](https://github.com/raviqqe/muffet) in a container linked to the to-be-released docs container to verify all URL's to be valid.
* 

**:link: Reference links**

* 


Story points: 3.0
Mutual TLS ability for inway -> service connection

**As a** sysadmin
**I want** mutual TLS encrypted connections between inway and API
**so that** all data connections are secure

There is no protection mechanism yet that can be used to secure services behind an inway. We would like to add some kind of mechanism to protect communication between the inway and the service as well.

**Acceptance criteria**
1. Ability to add client certificates to the inway service definition. This certificate is then used by the inway to connect to the service.
1. Ability to add trust configuration to the inway to determin whitch certificates from the api should be trusted by the inway.
1. Updated Documentation
1. Update all demo deployments

Story points: 5.0
Streamline process obtaining production certificates

**As an** administrator
<br>**I want to** to obtain pre-production and production certificates
<br>**so that** I can run NLX components in the production environment

**:white\_check\_mark: Acceptance criteria**

1. Explain the process for how to obtain certificates
1. Create 'Production` section on docs.nlx.io
1. ~~Maintainer documentation on how to help/validate customers that need a certificate~~
1. ~~Determine who is responsible in the team~~
1. ~~There is a backup of the PKI of the CA~~


**:link: Reference links**

* [Project Definition of Done](https://gitlab.com/commonground/nlx/nlx/blob/master/CONTRIBUTING.md#4-2-definition-of-done)

Story points: 5.0
Let inway use the config-api

**As an** administrator
<br>**I want to** be able to use the config-api to configure my inway
<br>**so that** i do not have to use the toml any more

**:white\_check\_mark: Acceptance criteria**

1. We add a new experimental flag `CONFIG_API` to tell the inway where the configuration API lives
1. The inway adopts the inway configuration, configures the corresponding services and checks every x seconds for new configuration, applies and reloads on a change.

Story points: 3.0