giseldo/neodataset huggingface dataset:
FRONTEND: Remove Algebra 2 header

A fast follow to running the migration script here https://gitlab.com/upchieve/subway/-/issues/1020, we should remove the algebra 2 launch header

Relevant areas of code: 
- src/views/DashboardView/VolunteerDashboard/index.vue
- src/components/App/AppHeader/AlgebraTwoLaunchHeader.vue

We can remove `AlgerbraTwoLaunchHeader.vue` file.

Searching `algebraTwoLaunchHeaderData` will show you all the snippets of code that calls the AlgebraTwoLaunchHeader. We also want to remove `isEligibleToSeeAlgebraTwoHeader` function that decides if we should show the header or not

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session

Story points: 1.0
BACKEND: Execute Algebra 2 cleanup migration on 3/1/22

We initially planned to use a Kubernetes cron job to execute the migration clean up, see details here: https://gitlab.com/upchieve/port-authority/-/issues/11

Due to time constraints and missing the deadline, we'll mainly run this migration script on 3/1/22

## Tasks
- [x] Run migration script against production

## Smoke tests
- [x] Check that no volunteer has algebraTwo-temporary

Story points: 0.0
FRONTEND: modal-pop up and hitting endpoint to update volunteer favorited status

* when clicked on opens modal to confirm whether user wants to favorite/unfavorite volunteer
* hits `POST /api/student/favorite-volunteer` to toggle the volunteer favorite status in the backend
* on error pop up error modal
  * if error is that student has max favorites include that in the modal

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session

Story points: 1.0
SPIKE: Whiteboard turning black

We have received a number of Gleap reports that the whiteboard turns black. If a user is on mobile, switching the phone from portrait mode to landscape mode sometimes fixes the problem. Switching from chat to whiteboard view has also been reported to fix the problem. Here are a few reports:

- https://app.gleap.io/share/tnezxCariq6hNOKiwNF5KQU4Dp32Xu19QvdhRAoaYRmDpUOlcCpd4McbJOL33Val2aEfpQ
- https://app.gleap.io/share/HISCiiPlkHyfctx5sljSUH1POEc8zAgk0FVD0SgC5pu1QOKVZHTJCQ0bxZ31IL6rw0ApSF
- https://app.gleap.io/share/BmKcshEj21iKrs19iZl6vhu6kxj5A5rve4LB6RK5666CVkpJtGGEgOuevdZMHJ6bdhIYLc
- https://app.gleap.io/share/NBjoAIBViwJNWEoZq8hC0xWed2GSuyVmPo2Pcv3qz4VSjevhIIww1R5MwogZsSJqfJwbNh
- https://app.gleap.io/share/LZuu1psDRrUbWiaL6HpNdYTmjvJVfyKHltGLAL9IYo8hZdvrWvRNOLXnO17HvmKE5TdyBy

Please investigate why the whiteboard is turning black, what are the causes of this bug, and document your findings


## Tasks
- [x] Investigate why the whiteboard turns black and document findings

Story points: 3.0
FRONTEND: dynamic favoriting question in feedback form

Add dynamic question to post session feedback forms (see copy in v2 post session feedback [here](https://www.figma.com/file/EaawhUyLG36EQDtJhKatzStS/WebApp-Redesign-2019?node-id=37%3A161))
* Non-CC sessions: students see an option to favorite their coach from the session if they rate the coach as a 4 or a 5
* CC sessions: students see an option to favorite their coach from the session if they rate the statement “I would like to receive help from this coach again” as a 4 or a 5
* Students do not see the question to favorite a coach, regardless of other answers, if the coach is already favorited
    * hit `GET /api/students/favorite-volunteer` to determine if they are already favorited
* Students should not see a question to favorite a volunteer if they're at max favorite limit
* DO NOT include question answer in feedback form save request
  * INSTEAD hit `POST /api/students/favorite-volunteer` with the session ID in the request body
* In the provided copy there are small changes like placeholder text in the volunteer feedback text box

* Backend: Make storing feedbacks an upsert, overwrite the entire `responseData` json

## Tasks
- [x] Code review
- [x] Staging smoke tests
- [x] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [x] Student/volunteer can login
- [x] Student/volunteer can make/join session
- [x] Student/volunteer can use whiteboard and chat in session
- [x] Student only sees question on correct conditions
- [x] Answering question changes volunteer favorite status

Story points: 3.0
Refactor the creation of the job temporary file path

## Summary

This issue is extracted from https://gitlab.com/gitlab-org/gitlab/-/issues/29407

From the comments https://gitlab.com/gitlab-org/gitlab/-/issues/29407#note_947110258 and https://gitlab.com/gitlab-org/gitlab/-/issues/29407#note_989127953

| Step | Status |
| ------ | ------ |
| 1. GitLab: Stop expanding file variables when sending to Runner | https://gitlab.com/gitlab-org/gitlab/-/issues/365859 |
| **2. Runner: Refactor the creation of the job temporary file path** | :point_left: You are here |
| 3. Fix file variables in Runner | https://gitlab.com/gitlab-org/gitlab/-/issues/29407 |

## Technical proposal

from: https://gitlab.com/gitlab-org/gitlab/-/issues/29407#note_935276800

Extract creation of the job temporary file path from the `ShellWriter` interface.

The path depends on the job data. Until it needs to be printed, there is nothing shell-dependent that needs to be considered.

I think that we should have the code that creates that path moved to the `common.Build` structure, and the `ShellWriter` implementations should focus on how to present the path and how to prepare the environment during the script execution for file creation there (like calling a shell/os dependent command to create a directory where temporary files are stored).

Story points: 3.0
[UI/UX] Add option in CI/CD settings for variable expansion

## Description

In the .gitlab-ci.yml file, a user can define a variable and use it in another variable definition within the same `.gitlab-ci.yml` file. gitlab-org/gitlab-runner#1809

Users also need to be able to allow nested variables through the applications' UI.

## Proposal

**[:star: SEE PROTOTYPES ON FIGMA :star:](https://www.figma.com/file/TNu09pr4KX4dqxtQ1Tslvs/Runner-Usability-improvements?node-id=406%3A767)**

* Under project `Settings > CI/CD > Variables`, we will add an option for users to enable/disable nested variables in the ci file.
* ~frontend - A checkbox button is added to the section.
  * The option is **not** selected by default.
* ~frontend - Users need to click the `save changes` button to apply their option.
  * A feedback notification is displayed using the ~"component:toast" - https://design.gitlab.com/components/toast/
  * https://design.gitlab.com/product-foundations/saving-and-feedback
* ~"Technical Writing" - The ~"UI text" of the Variables section will also be updated.

### Permissions and Security

Permissions should be consistent with the existing permissions structure regarding which roles can access project settings https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions

* [ ] Members with no access (0) should not be able access the project settings
* [ ] Guest (10) members should not be able to access the project settings
* [ ] Reporter (20) members should not be able to access the project settings
* [ ] Developer (30) members should be able to access the project settings
* [ ] Maintainer (40) members should be able to see and interact with the option in the project settings
* [ ] Owner (50) members should be able to see and interact with the option in the project settings

### Documentation

We should update https://docs.gitlab.com/ee/ci/variables/

## Links to related issues and merge requests / references

gitlab-org/gitlab-runner#1809

gitlab-org/gitlab-runner#26345

Story points: 2.0
Pass `multi_build_steps` as a Runner Feature when requesting a job

Issue https://gitlab.com/gitlab-org/gitlab/-/issues/199250 exposes a new `.gitlab-ci.yml` syntax for creation of releases, using the [releaser-cli](https://gitlab.com/gitlab-org/release-cli). 

```yaml
release_job: {
  stage: 'release',
  only: 'tags',
  script: ['make changelog | tee release_changelog.txt'],
  release: {
     name: 'Release $CI_COMMIT_SHA',
     description: 'Created using the release-cli $EXTRA_DESCRIPTION',
     tag_name: 'release-$CI_COMMIT_SHA',
     ref: '$CI_COMMIT_SHA'
  }
```

The Runner then calls the `releaser-cli` with this command line:

```bash
release-cli create --name "Release $CI_COMMIT_SHA" --description "Created using the release-cli $EXTRA_DESCRIPTION" --tag-name "release-$CI_COMMIT_SHA" --ref "$CI_COMMIT_SHA"
```


The Runner has already been extended with [this MR](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6409). An additional change in required to pass the supported runner features to Rails.

A new feature called `multi_build_steps` has been created, and this needs to be passed to the `POST /api/v4/jobs/request` endpoint, populating the `:features` field.

Please also see this note https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27810#note_361591716

> Runner is passing features supported when requesting a job - https://gitlab.com/gitlab-org/gitlab/-/blob/df71d756e4955b98bbb4add5cf43cd27c09cc6c7/lib/api/runner.rb#L101 and then `Ci::RegisterJobService` is checking can the runner support the selected job - https://gitlab.com/gitlab-org/gitlab/-/blob/df71d756e4955b98bbb4add5cf43cd27c09cc6c7/app/services/ci/register_job_service.rb#L104. In case it's not the job is dropped with *"Your runner is outdated, please upgrade your runner"* failure reason.

Story points: 1.0
Add integration test for Docker executor to check each step is executed

### Overview

In https://gitlab.com/gitlab-org/gitlab/-/issues/215037 we had a ~regression where the `after_script` was not running inside of the docker executor. This has shown a test gap in out integration tests for the Docker executor, we aren't making sure that each section/stage of the job is being executed.

### Proposal

Update tests like [`TestDockerCommandSuccessRun`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/dae4647d17825dd2b43c0d6a1e7ad919150be88a/executors/docker/docker_command_test.go#L68-77),  [`TestDockerCommandBuildFail`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/dae4647d17825dd2b43c0d6a1e7ad919150be88a/executors/docker/docker_command_test.go#L215) and validate that each stage runs:

- before_script
- script
- after_script

Other steps should be validated in a follow-up issue https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26839

Story points: 2.0
Implement session endpoint to proxy build services requests

As a part of https://gitlab.com/gitlab-org/gitlab-ee/issues/5276 we need to implement extend the build session and add a new endpoint that will be able to proxy requests coming from Rails-Workhorse to a specific service running in the build.

The endpoint will be something like `/session/uuid/proxy/<build|or|service-name>/<port>/<requested-uri>`.

This proxy mechanism should be able to be bi-directional. In this situation, we would need to handle websocket connections automatically. If the request is not a websocket one the proxy would act as an unidirectional reverse proxy.

Story points: 3.0
Add support for interactive web terminal to Docker executor

## Description

So far we have added support in the interactive web terminal for `kubernetes` and `shell` executors; this issue adds support for the `docker` executor, which is used both by onsite installations on extensively on gitlab.com. This is purely a limitation of the runner and no other systems should be involved.

## Proposal

Have the docker executor implement the `InteractiveTerminal` and `Conn` interface from the `terminal` package. Use [`gitlab-terminal`](https://gitlab.com/gitlab-org/gitlab-terminal) to proxy connection to the WebSocket, issue for [`gitlab-terminal`](https://gitlab.com/gitlab-org/gitlab-terminal) to add support can be found in gitlab-org/gitlab-terminal#3

### Keep container runner when terminal attached 

By design, docker will stop the container when the pid 1 is finished. Meaning when the script has finished running it will stop the container, which is not what we want if the user is connected to the terminal, we want to keep the container running. Doing this requires behavioural changes to the docker executor inside of the runner, which are listed blow.

#### Add `tail -f /dev/null`

Adding `tail -f /dev/null` at the end of the script will keep the container running forever and then the runner is responsible of stoping the container either when the user closes the terminal connection, or the main script as finished. 

Pros:

- Don't change current runner behaviour

Cons:

- If `tail` is not present in the container this will not work
- Will be quite hard to know when to kill the container if the user is connected, or if the script is still running (since the script will run forever)

### Run container in detached mode 

For certain containers, it is possible to keep the container running by doing the following `docker run -t -d centos` this will the container running since the default command is `bash`. After we start the container like that we will execute the script via `docker exec` and then stop the container when the `exec` is done or when the terminal connection is closed/timed out

Pros:

- Cleaner solution
- No hacks
- Same flow as the kubernetes executor

Cons:

- Changing workflow of runner 

## Limitation of Docker executor

For the Docker executor, as soon as the build script is finished (meaning what the user specified to run in `.gitlab-ci.yml`) the terminal will close. So:

- Build starts
- User connect to terminal, build script is running at the same time
- Build script finished

Now, normally what would happen is the timeout countdown starts ticking (this works for k8s and shell executors). For Docker, this will close immediately. The reason for that is a technical one on how docker behaves by default.

As direct result it would be, for the Docker executor, the terminal is only available while the build is running.

This will be resolved via https://gitlab.com/gitlab-org/gitlab-runner/issues/3605, giving users a way to enable this behavior.

## Links to related issues and merge requests / references

gitlab-org/gitlab-ce#25990

gitlab-org/gitlab-terminal#3

Story points: 5.0
Updates for Documentation - Autoscaling

Based on https://gitlab.com/gitlab-org/gitlab-runner/blob/master/docs/install/autoscaling.md

## docs/install/autoscaling.md

* The link at `GitLab Runner installation documentation` goes to the GitLab repository (not relevant here), but should go to https://docs.gitlab.com/runner/install/
* Docker Registry and Cache Server may not only be relevant when running in autoscaling. I would suggest to move it to a separate page

Original issue: https://gitlab.com/gitlab-org/gitlab-runner/issues/2531

Story points: 1.0
/cache volume is always added to volumes list

### Summary

When adding additional volumes via `register --docker-volume`, /cache is still added, even if a different volume for /cache is submitted.

### Steps to reproduce

run the register command in --non-interactive mode and append `--docker-volumes /srv/gitlab-runner/cache:/cache`

check the created config.toml

`volumes = ["/srv/gitlab-runner/cache:/cache", "/cache"]`


### What is the current *bug* behavior?

see "steps to reproduce"

### What is the expected *correct* behavior?

gitlab-runner either automatically detects that /cache is already provided in a volume and doesn't add it a second time, or (since this might be hard to detect) at least offers a switch that disables automatically adding this volume, maybe with a warning attached that the user then must provide the volume mount point manually.

### Relevant logs and/or screenshots

The offending code seems to be at
https://gitlab.com/gitlab-org/gitlab-runner/blob/master/commands/register.go#L108

`s.Docker.Volumes = append(s.Docker.Volumes, "/cache")`

There are no checks if it is even necessary and no way to disable this.

### Possible fixes

- Manually edit the config file after generation, removing the "/cache" entry (my current workaround, not a good solution)
- Add a switch to give a more precise location for the "/cache" volume.
- Add a switch to disable automatically adding "/cache" to the volumes list.
- Automatically detect if a "/cache" volume is provided already by --docker-volumes and don't add "/cache" in these cases.

Story points: 1.0
Updates for Documentation - Docker

Based on https://gitlab.com/gitlab-org/gitlab-runner/blob/master/docs/install/docker.md

## docs/install/docker.md

* mounting docker containers as data volume is not anymore state of the art. Use `$ docker volume` to create a volume
* The syntax for docker `$ docker run` is outdated (as of version `17.03`) Use `$ docker container run`
* Mounting docker sockets: you mention the same `$ docker run` command twice in the chapter `## Docker image installation and configuration`


Story points: 1.0
allow access at registration time  to be able to the runner active: false

## Description

We should add another improvement that will set active: false attribute for a registered Runner on GitLab's side. But this would need first an update in GitLab CI API in here https://gitlab.com/gitlab-org/gitlab-ce/blob/v8.15.0/lib/ci/api/runners.rb#L32.

## Proposal

--active=false or --active=true ( default)

## Links to related issues and merge requests / references

> Please paste a link of the related issues or/and merge requests

Story points: 2.0
Aliases for services docker images

We're really enjoying using GitLab CI with the container registry feature. However, we are struggling to use the "services" feature with our internally-defined docker images (from the GitLab container registry and another registry).

We need to be able to use services where the image names are long and complicated, e.g.:

```yaml
job:
    image: git.example.com:9999/group/project-a:latest
    services:
        - other-registry.example.com:9999/group/project-b:1.0
        - git.example.com:9999/group-b/project-c:develop
```

It would really help if we could specify network aliases for each of these services (docker-compose allows something like this) e.g.:

```yaml
job:
    image: git.example.com:9999/group/project-a:latest
    services:
        - backend:git.example.com:9999/group/project-b:1.0
        - db:git.example.com:9999/group-b/project-c:develop
    script:
        - curl http://backend
        - curl http://db
```


Story points: 9.0
Namespace dropdown doesn't default to the namespace in the URL params

Namespace dropdown doesn't default to the namespace in the URL params since its looking for namespace id on a non-existent order (`current_namespace_id: @order&.gl_namespace_id` in `_new_gitlab_com_subscription.html.haml` but on new subscription purchase flow, the order is yet to be created).

Since we're in related area, it's also worth removing non-applicable reference to subscription when creating a new SaaS subscription.

![Screen_Shot_2022-05-24_at_6.40.35_PM](/uploads/5e37c52bb52f413fabced01e10453b13/Screen_Shot_2022-05-24_at_6.40.35_PM.png)

Created from [this note](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3242#note_653915057)

> In `app/views/subscriptions/_new_gitlab_com_subscription.html.haml`:

> * If we are creating a new subscription, there should be no `subscription_id` params, thus no `@subscription` and no `@order`.
> * `current_namespace_id` is required to set the default selected namespace, but should it be from `params[:gl_namespace_id]` instead of from `@order&.gl_namespace_id`?

> ```
> #js-new-gitlab-com-subscription{ data: { subscriptions_path: subscriptions_path,
>   plan_id: @plan.id,
>   plan_name: @plan.name,
>   customer: CustomerPresenter.new(current_customer).present.to_json,
>   subscription: @subscription ? SubscriptionPresenter.new(@subscription, current_customer).present : nil,     <---
>   namespaces: gitlab_namespaces_for_select.to_json,
>   namespaces_with_paid_plan: gitlab_namespaces_ineligible_for_purchase_ids,
>   current_namespace_id: @order&.gl_namespace_id,                                                              <---
>   seat_price: @plan.price,
>   payment_methods: @payment_methods.to_json } }
> ```

 <br/>

`init_new_gitlab_subscription.js` and `new_gitlab_subscription_form.vue` might need some cleanup with the above changes to remove `subscription` usage.

A couple of things to make sure with the changes:

1. The default selected namespace when visiting the new SaaS subscription page should be the one in the params (this is broken currently since its looking for namespace on non-existent order for yet to be purchased subscription)
2. We're still able to preview transaction when selecting different namespaces with correct prices and purchasing new subscription still works as before

Story points: 2.0
[BE] Emoji in Customer name causes errors interacting with Zuora

### Problem

Customers are able to set emoji in their names in CustomersDot accounts. When we try to make a subscription purchase, we take the `bill_to_contact` details from the Customer record in the CustomersDot app. This results [in the following error from Zuora:](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/3267234/events/76539035/)

```ruby
Body: [{"Success"=>false, "Errors"=>[{"Code"=>"UNKNOWN_ERROR", "Message"=>"Operation failed due to an unknown error."}]}]
```

<img src="/uploads/97e77d6dcc65d008dc0e8d5144c528c4/CleanShot_2022-05-09_at_15.05.09.png" width='500px' />

### Steps to reproduce

1. Create a new account on Gitlab
3. Navigate to CustomersDot and select `sign in with Gitlab`
4. Fill out the details to register for a customers dot account, and add an emoji to the first name
5. Create a group on GitLab and navigate to billing
6. Select a plan, fill out the details and submit the purchase
7. There is an `UNKNOWN_ERROR` message

<img src="/uploads/5901d4353e4af31417b9a499a1a3d103/CleanShot_2022-05-09_at_14.54.59.png" width='500px' />

#### Workaround

Once the emoji is removed from the name on the customers dot account, the purchase completes successfully.

### Proposal

1. Don't allow customers to create or edit their account to have emoji in their: `first_name, last_name, company`

Story points: 3.0