giseldo/neodataset huggingface dataset:
UX: Format Jam3 Home Page to Slippers UI

## Goal
We would like to skin the home page with new branding which will improve the look and feel of our Enterprise company as measured by more traffic to our site.

### Jobs To Be Done
* **Situation**: *When we want to present GitLab as an Enterprise brand...*
* **Motivation**: *We want to update the look and feel of our site...*
* **Outcome**: *So we can reflect externally how we operate internally.*

## Page(s)
Which page(s) are involved in this request?
* [Figma designs](https://www.figma.com/file/hKvIRhVlrgXrB1WcyuDBiQ/Home-Page-Refresh-2022-03-29?node-id=208%3A4259)

## DCI
[DRI, Consulted, Informed](https://about.gitlab.com/handbook/people-group/directly-responsible-individuals/#dri-consulted-informed-dci)

- [ ] DRI: @jhalloran 
- [ ] Consulted: @lduggan 
- [ ] Informed: `Everyone`

## In scope
What is within scope of this request?

- [ ] Home page mocks

## Out of scope
What is out of scope and not part of this iteration?

- Not in scope 1
- Not in scope 2

## Requirements
What are the requirements for this request? Checklist below is an example of common requirements, please check all that apply and adjust as necessary:

- [ ] Copy writing
- [ ] Illustration
- [ ] Custom Graphics
- [ ] Research
- [ ] Data / Analytics
- [x] UX Design
- [ ] Engineering

Story points: 2.0
Add deprecation note to GitLab deprecations regarding KAS private tls

### What is this issue about?

The `gitlab.kas.privateApi.tls.enabled` and `gitlab.kas.privateApi.tls.secretName` attrs were deprecated following the linked discussion below.

The following discussion from !2888 should be addressed:

- [ ] @Alexand started a [discussion](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2888#note_1220328090): 

    > I'm not sure if deprecating `gitlab.kas.privateApi.tls.*` is the best way forward. But my reasoning was:
    > 
    > 1. I want to simplify the chart options. So it's probably better to have just one documentation section explaining how to enable TLS for KAS.
    > 1. Having a global attribute to configure TLS for KAS across the chart gives us more power to automate these configurations. Right now, GitLab webservice needs KAS address (`grpc` vs `grpcs`). A configuration value that lives inside of the KAS sub-chart can't do it.
    > 1. I can't immediately think of a reason why one would want to enable just certain KAS servers with TLS, but not others.
    > 1. I don't think we'd need different certificates per KAS server, or any other TLS specific configuration that would be used differently for each KAS service.
    > 
    > _I'm leaving this thread open in case reviewer and maintainer have any thoughts regarding this._

This issue is to track adding a deprecation note to https://docs.gitlab.com/ee/update/deprecations.html.

### Deprecation note proposal

Planned removal: GitLab 17.0 (2024-05-22)

The GitLab chart provides `gitlab.kas.privateApi.tls.enabled` and `gitlab.kas.privateApi.tls.secretName` to support TLS communication between KAS pods. To enable TLS communication between KAS and all other chart components that KAS needs to communicate to, one needs to set many other extra Helm values.

To facilitate enabling TLS communication between KAS and all the chart components, we've introduced the `global.kas.tls.*` Helm values. Since this is a more complete and simple approach to enabling TLS for KAS. We recommend you stop using `gitlab.kas.privateApi.tls.*` Helm values, and use `global.kas.tls.*` instead. Therefore, the `gitlab.kas.privateApi.tls.*` is deprecated and scheduled for removal in 17.0. For more information please refer to:

- The [Merge Request](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2888) which introduces the `global.kas.tls.*` values.
- The [deprecated documentation](https://docs.gitlab.com/charts/charts/gitlab/kas/index.html#enable-tls-communication).
- The new preferred documentation. (link to be added)

/cc @nmezzopera @nagyv-gitlab

Story points: 1.0
Document how to connect KAS to Redis via SSL

<!--
NOTICE: This Issue tracker is for the GitLab Helm chart, not the GitLab Rails application.

Support: Please do not raise support issues for GitLab.com on this tracker. See https://about.gitlab.com/support/
-->

## Summary

This is a follow-up from https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2829

KAS can do ssl communication with Redis. We should test this with the GitLab chart and document it.

Story points: 2.0
Improve UX to enable TLS to KAS externally and internally

<!--
NOTICE: This Issue tracker is for the GitLab Helm chart, not the GitLab Rails application.

Support: Please do not raise support issues for GitLab.com on this tracker. See https://about.gitlab.com/support/
-->

## Summary

We've recently introduced a way to mount certificate volumes into KAS pods. This enables KAS to talk internally and externally through TLS.

But the implementation is only simply to use for the `privateApi` via the `privateApi.tls.enabled` attribute.

We should make it also simple to other KAS endpoints to enable TLS, instead of relying on them to use `gitlab.kas.customConfig` and `privateApi.tls.enabled`.


### Proposal

Maybe a global key that tells KAS to enable it for all its components would make more sense.

Story points: 3.0
Improve communication regarding how to install the Agent when running GitLab with custom certificates

## Release notes

Setting up the KAS component of the agent for Kubernetes with custom certificates and using the CI/CD integration is a rather complex task. To support our users who require custom certificates, we updated the documentation for better support. The documentation touches on how to set up KAS, agentk and how to invoke `kubectl` commands from Gitlab CI/CD with custom certificates.

## Proposal

The following discussion from !2803 should be addressed:

- [ ] @dmakovey started a [discussion](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2803#note_1133710036):  (+4 comments)

    > LGTM.
    > 
    > something for further iterations (i.e. new issues?):
    > 
    > Based on findings in https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2803#note_1133461689 it looks like mere setup of documented values is not sufficient for proper TLS function with custom CA certs, so can we:
    > 
    > 1. add documentation for custom (including self-signed) CA authorities or point at existing one
    >    1. how to reuse `gitlab-wildcard-tls-ca` 
    >    2. (optional) sort out how to add custom CA cert for `kubectl` rather than use `--insecure-skip-tls-verify` as that's not a proper solution to the problem.
    > 
    > @Alexand what do you think?

Story points: 2.0
Enable KAS by default on the GitLab chart

The following discussion from !2436 should be addressed:

- [ ] @nagyv-gitlab started a [discussion](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2436#note_872540922):  (+1 comment)

    > @Alexand Is this true? Did we enable `kas` by default only in Omnibus?

We already have `kas` enabled by default on Omnibus. Now we need to also enable it on the GitLab chart.

Story points: 2.0
Remove non_test group specification on bundle install

## Summary

!322 introduced `non_test` group to Gemfile by @Ahmadposten (around %11.1), but very soon after it, it was removed in !404 (%11.2).

## Why
This change would eliminate unnecessary deprecation warning from the CI job log:

```
$ bundle install -j $(nproc) --without non_test
[DEPRECATED] The `--without` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set without 'non_test'`, and stop using this flag
```

https://gitlab.com/gitlab-org/charts/gitlab/-/jobs/1126027482

Story points: 1.0
Support deployment of gitlab-sshd (gitlab-charts)

## Summary

Support the use of `gitlab-sshd` as a component within the GitLab Shell container / chart of Cloud Native Gitlab.

## Details 

2020-01-1 saw the merge of https://gitlab.com/gitlab-org/gitlab-shell/-/merge_requests/394, and we [can now begin integration](https://gitlab.com/gitlab-org/gitlab-shell/-/merge_requests/394#note_488121893). 

`gitlab-sshd` is designed to provide a replacement to the use of `sshd` from OpenSSH, and can be the single service started by a container using it.

## Work items

1. Build and support configuration within `gitlab-shell` of the CNG containers
    - binary
    - process-wrapper / entrypoint & logging
1. Support for configuration within `gitlab/gitlab-shell` chart

Story points: 2.0
Support Embedded Action Cable in Helm Charts

<!--
NOTICE: This Issue tracker is for the GitLab Helm chart, not the GitLab Rails application.

Support: Please do not raise support issues for GitLab.com on this tracker. See https://about.gitlab.com/support/
-->

## Summary

We introduced support for running Action Cable in embedded mode in Omnibus https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4407. It can be enabled by setting the `ACTION_CABLE_IN_APP` environment variable. This was enabled in docker-compose in https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/504.

We need to expose this environment variable via the Helm chart so that it can be set on `webservice` pods when deployed via K8s.

We should also support setting the `ACTION_CABLE_WORKER_POOL_SIZE` environment variable. Both are non-secret.

We've also created a [container](https://gitlab.com/gitlab-org/build/CNG/-/tree/master/gitlab-actioncable) specifically for running Action Cable in a standalone Puma server so it can be scaled independently. This is probably what will be used on gitlab.com and Helm chart work towards that is being tracked in https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2284.

See also: https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2043

## Detail

#### In Omnibus

- Action Cable is disabled by default;
- Action Cable is enabled in Omnibus using the `actioncable['enabled']` setting;
- By default, a separate Action Cable server is started that only serves WebSocket connections. To run it in embedded mode, as part of the same Puma server, the `actioncable['in_app']` setting is used, and
- Action Cable thread pool size is configured with the `actioncable['worker_pool_size']`.

#### In CNG

- A separate `actioncable` container exists, which can be scaled independently;
- Action Cable can be run in embedded mode on the `webservice` container by passing in the `ACTION_CABLE_IN_APP` envvar;
- Max AC thread pool size is configured with the `ACTION_CABLE_WORKER_POOL_SIZE` environment variable, and
- Workhorse accepts a `cableBackend` argument which accepts a service name and port and can proxy WebSocket requests to the correct service. It defaults to the same as the `authBackend` setting.

An example of a setup proxying requests to a `webservice` container running embedded Action Cable is in the CNG [docker-compose.yml](https://gitlab.com/gitlab-org/build/CNG/-/blob/master/docker-compose.yml) file.

Currently, Action Cable is only supported for the Puma server, not Unicorn.

## Proposal

Modify GitLab Helm chart to allow configuration of Action Cable in embedded mode.

Story points: 5.0
CNG: `gitlab-rails-ce`/`gitlab-rails-ee` sometimes fail at the NodeJS downloading step

## Summary

See:

- https://gitlab.com/gitlab-org/build/CNG-mirror/-/jobs/499481345

```
 Step 26/63 : RUN curl -fsSL "https://nodejs.org/download/release/v${NODE_VERSION}/node-v${NODE_VERSION}-linux-x64.tar.gz"   | tar --strip-components 1 -xzC /usr/local/
  ---> Running in 68a08e4dd34c
 curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
 gzip: stdin: unexpected end of file
 tar: Unexpected EOF in archive
 tar: Unexpected EOF in archive
 tar: Error is not recoverable: exiting now
 The command '/bin/sh -c curl -fsSL "https://nodejs.org/download/release/v${NODE_VERSION}/node-v${NODE_VERSION}-linux-x64.tar.gz"   | tar --strip-components 1 -xzC /usr/local/' returned a non-zero code: 2
```

- https://gitlab.com/gitlab-org/build/CNG-mirror/-/jobs/499787651

```
 Step 27/65 : RUN curl -fsSL "https://nodejs.org/download/release/v${NODE_VERSION}/node-v${NODE_VERSION}-linux-x64.tar.gz"   | tar --strip-components 1 -xzC /usr/local/
  ---> Running in 0580fc35e278
 curl: (22) The requested URL returned error: 500 
 gzip: stdin: unexpected end of file
 tar: Child returned status 1
 tar: Error is not recoverable: exiting now
 The command '/bin/sh -c curl -fsSL "https://nodejs.org/download/release/v${NODE_VERSION}/node-v${NODE_VERSION}-linux-x64.tar.gz"   | tar --strip-components 1 -xzC /usr/local/' returned a non-zero code: 2
```

These are two different errors, but at the same step:


## Current behavior

Upstream codebase server issued a `500`, but the Job immediately failed

## Expected behavior

Fetch of upstream to retry in the event of a failure, (hopefully) allowing the rest of the job to succeed.

## Versions

CNG @ 3c7ef1ba18a2c361139975379f16c8b00f7156a5

## Relevant logs

See above.

Story points: 2.0
Consider caching gems to make the gitlab-rails-ce job faster and more resilient when Rubygems has problems

Rubygems seems to currently have problems, which leads to problems in our CI pipelines (e.g. https://gitlab.com/gitlab-org/build/CNG-mirror/-/jobs/207740638).

If we'd cache the `vendor/ruby` folder, [similarly to how we do for the CE/EE pipelines](https://gitlab.com/gitlab-org/gitlab-ce/blob/f7bba29cb573e74b56aba7882048aac7de0d6868/.gitlab/ci/global.gitlab-ci.yml#L14) we would make the jobs faster and more resilient to Rubygems issues.

Story points: 4.0
SCORU: WASM: Tickify module initialization

`Eval.init` from the WebAssembly reference interpreter needs to be tickify. It has a significant time complexity cost and must be broken up.

!5552 introduces lazy vectors instead of list for the module fields, which are then converted into list in `init`, then back to lazy vectors. Tickification can remove these conversions roundtrip by directly going from lazy vector to lazy vector, and evaluate the fields as small steps.

Remaining:
- Remove all uses of to_list/concat/of_list from `Eval.init`

Story points: 5.0
Make tezos-proxy-server honor /chains/main/block/head/header

`Tezos Commons` is willing to use `tezos-proxy-server` in their deployment. Their main target is to use it for `run_operations`, which works already :muscle:. However, they were surprised that it is not serving `/chains/main/block/head/header` too.

Indeed `tezos-proxy-server` doesn't serve it, because it is registered in a resto `Directory` in `block_directory.ml` while the proxy server serves `Plugin.RPC.rpc_services`. If we were to do this, it would go something like:

```diff
--- a/src/proto_alpha/lib_client/proxy.ml
+++ b/src/proto_alpha/lib_client/proxy.ml
@@ -163,6 +163,28 @@ let init_env_rpc_context (_printer : Tezos_client_base.Client_context.printer)
   initial_context proxy_builder rpc_context mode chain block >>= fun context ->
   return {Tezos_protocol_environment.block_hash; block_header = shell; context}
 
+let block_services_dir (rpc_context : RPC_context.json) =
+  let open Protocol in
+  let module Directory = Resto_directory.Make (RPC_encoding) in
+  let rpc_context = new Protocol_client_context.wrap_rpc_context rpc_context in
+  let open Tezos_shell_services in
+  let path =
+    let open Tezos_rpc.RPC_path in
+    prefix Block_services.chain_path Block_services.path
+  in
+  let service =
+    Tezos_rpc.RPC_service.prefix path Block_services.Empty.S.header
+  in
+  Directory.register Directory.empty service (fun (((), chain), block) ->
+      let res =
+        Protocol_client_context.Alpha_block_services.header
+          rpc_context
+          ~chain
+          ~block
+          ()
+      in
+      assert false)
+
```

or exposing `proxy.ml`'s `proxy_block_header` function in some way.

Story points: 24.0
Gossipsub: Remove peers from the mesh and fanout on unsubscribe

Remove peers from the topic mesh when the peer unsubscribes from the topic, as done in the [rust implementation](https://github.com/libp2p/rust-libp2p/blob/b7ba0f728633c1c0e0bc67339e5b5002bb9adb0f/protocols/gossipsub/src/behaviour.rs#L2029).

Additionally, we remove the peers from the fanout on unsubscribe. This is not done in go/rust (they wait until the next heartbeat for the fanout to be cleaned) but we do it in unsusbcribe as it makese sense and is more consistent with the cleaning of mesh on unsubscribe.

Story points: 100.0
Gossipsub: Fix logic for publishing to direct peers

From https://gitlab.com/tezos/tezos/-/merge_requests/8248#note_1332465561

> In our implementation, the `direct` peers are only considered in the case where
>
> * mesh is empty for the topic.
> * fanout is empty for the topic.
>
>(i.e. the `match fanout_opt with | None ->` case above)
>
> But in the go implementation, the message is published to the `direct` peers regardless of the `mesh`/`fanout` emptiness: https://github.com/libp2p/go-libp2p-pubsub/blob/56c0e6c5c9dfcc6cd3214e59ef19456dc0171574/gossipsub.go#L997

Story points: 100.0
[GS Automaton] clarify/improve Heartbeat output for prune

The automaton currently outputs values of the following type for heartbeat:
```ocaml
    | Heartbeat : {
        (* topics per peer to graft to *)
        to_graft : Topic.Set.t Peer.Map.t;
        (* topics per peer to prune from *)
        to_prune : Topic.Set.t Peer.Map.t;
        (* set of peers for which peer exchange (PX) will not be proposed *)
        noPX_peers : Peer.Set.t;
      }
        -> [`Heartbeat] output
```

It seems that the information contained in `to_prune` field don't allow to call `handle_prune`, which requires inputs of type:
```ocaml
  type prune = {
    peer : Peer.t;
    topic : Topic.t;
    px : Peer.t Seq.t;
    backoff : span;
  }
```

In fact, fields `px : Peer.t Seq.t;` and `backoff` (per "peer and topic" ?) are missing

See which function needs to be modified: heartbeat or prune?

Story points: 100.0
Gossipsub: get_peers should not return peers that are waiting for expiration

In our implementation, `connection.expire` is used to keep the `connection` in the `connections` for a while after `remove_peer`.

Since peers with a non-none `connections.expire` is a removed peer which is wating for being expired, we shouldn't return them in the `get_peers` function [here](https://gitlab.com/tezos/tezos/blob/de253082858204509d4e91c9c079736abaf8d440/src/lib_gossipsub/tezos_gossipsub.ml#L653).

Story points: 100.0
Gossipsub: backoff and connection clearing

In the Go implementation:
* `RemovePeer` removes the peers from the state, but does not update the backoffs at all
* the backoffs are removed independently from `RemovePeer`, based on time alone, during heartbeat

In our implementation:
* `RemovePeer` sets an expiring time for the connection, using the `retain_duration` constant
*  the backoffs **and** the connection are possibly removed (based on their expiring times) during the heartbeat; in particular, a connection is removed only if there are no backoffs associated.

I opened this issue to :
- check that this makes sense
- see whether there are obvious simplifications

Story points: 50.0
Gossipsub: Score check is missing for IWant

The following discussion from !7594 should be addressed:

- [ ] @linoscope started a [discussion](https://gitlab.com/tezos/tezos/-/merge_requests/7594#note_1296353868): 

    > The score check is missing ([go implementation](https://github.com/libp2p/go-libp2p-pubsub/blob/56c0e6c5c9dfcc6cd3214e59ef19456dc0171574/gossipsub.go#L699))

Story points: 100.0
Gossipsub: Grafting with negative score

The following discussion from !7594 should be addressed:

- [ ] @linoscope started a [discussion](https://gitlab.com/tezos/tezos/-/merge_requests/7594#note_1296319510):  (+1 comment)

    > We are missing the score check ([go implmenetation](https://github.com/libp2p/go-libp2p-pubsub/blob/56c0e6c5c9dfcc6cd3214e59ef19456dc0171574/gossipsub.go#L801)). Feel free to address in a future issue, but let's be careful not to forget.

Story points: 100.0
lib_store: higher level of verbosity for a few events

```
2023-01-24T14:31:21.199-00:00 [validator.blockprechecked_block] prechecked block BMHjBfXHWQs2S93kcRtVcXsMskmvSqHaaLuB8pU2rJTgwFbQQwm
2023-01-24T14:31:21.199-00:00 [node.storestore_prechecked_block] prechecked block   BMHjBfXHWQs2S93kcRtVcXsMskmvSqHaaLuB8pU2rJTgwFbQQwm (level: 31) was stored
2023-01-24T14:31:21.214-00:00 [node.storestore_block] block BMHjBfXHWQs2S93kcRtVcXsMskmvSqHaaLuB8pU2rJTgwFbQQwm (level: 31) was   stored
2023-01-24T14:31:21.214-00:00 [validator.blockvalidation_success] block BMHjBfXHWQs2S93kcRtVcXsMskmvSqHaaLuB8pU2rJTgwFbQQwm validated   Request pushed on 2023-01-24T14:31:21.182-00:00, treated in 8.306us, completed in 31.838ms
2023-01-24T14:31:21.215-00:00 [node.storeset_head] BMHjBfXHWQs2S93kcRtVcXsMskmvSqHaaLuB8pU2rJTgwFbQQwm (level: 31) set as new   head
2023-01-24T14:31:21.216-00:00 [validator.chainhead_increment] Update current head to BMHjBfXHWQs2S93kcRtVcXsMskmvSqHaaLuB8pU2rJTgwFbQQwm   (level 31, timestamp 2022-10-13T16:06:50-00:00, fitness   02::0000001f::::ffffffff::00000000), same branch
```

Store events creates a lot of noise when treating a block. These events should probably be in `Debug` instead of `Info`.

Story points: 1.0
File-descriptor sink: missing dot between section and event name

fixed by https://gitlab.com/tezos/tezos/-/merge_requests/7494

```
2023-01-24T14:37:11.559-00:00 [validator.chainhead_increment] Update current head to BMHUKJJdXtPEipwTM5SsxRQCE76qbbWnsXibA75sYY6shNcsUJU   (level 10009, timestamp 2022-10-15T19:23:45-00:00, fitness   02::00002719::::ffffffff::00000001), same branch
```

```
2023-01-25T09:49:00.128-00:00 [validator.chain.head_increment] Update current head to BMJNPjiw1DkYn3NXoo6D4UQwBpyDT3rz7zmJ2mANWwxU9YFC1wn   (level 563573, timestamp 2023-01-24T14:22:35-00:00, fitness   02::00089975::::ffffffff::00000000), same branch
```

`validator.chainhead_increment` -> `validator.chain.head_increment`

Story points: 1.0
Node logs: simplify bootstrap logs

Already done in a previous [non-merged request](https://gitlab.com/tezos/tezos/-/merge_requests/2344/diffs?commit_id=1916f683d6b0ed705543b3fc42bcd249e970a122).

```
Dec  4 11:54:19.581 - node.validator.bootstrap_pipeline: fetching branch of about 10499 blocks from peer
Dec  4 11:54:19.581 - node.validator.bootstrap_pipeline:   idqrpoSMD3XKbsN5U8wqyT2d4SLfgv in 98 steps
```

The section is extremely long and the wording is could be simplified.
The solution could be the following one.

```
Dec  4 14:34:25.754 - bootstrap: fetching ~11741 blocks from peer ids9jAYxv8h4kWTi6swki3fXfTEUG1 in 100 steps
```

Story points: 1.0