- Sep 29, 2024
-
-
Archish Thakkar authored
-
- Jul 24, 2024
-
-
Ash McKenzie authored
-
- May 28, 2024
-
-
Kyle Edwards authored
Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/336618
-
- May 07, 2024
-
-
Joseph Snyder authored
Try to get ahead of future comments by running the lint test locally and fixing issues that are found. * More variable capitalization issues * More unused variables -> "_"
-
- Apr 22, 2024
-
-
gaurav.marwal authored
-
- Apr 17, 2024
-
-
Vasilii Iakliushin authored
Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/442907 **Problem** We discovered that reliance on project and namespace paths is not sufficient. User can rename the group or project and that might lead to problems with identifying the correct project/namespace. **Solution** Instead of project/namespace path we should use their IDs. Changelog: added
-
- Jan 25, 2024
-
-
Joseph Snyder authored
Per review: Properly match error created to function name for Unlock Consistently use variable types in all function definitions Remove Lock function which isn't part of the standard Switch if statement to be more readable
-
Joseph Snyder authored
Using new names and looking for the correct link in output.
-
Kyle Edwards authored
Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/336618
-
- Aug 22, 2023
-
-
Ash McKenzie authored
LogData also contains a new LogMetadata struct
-
- Jul 04, 2023
-
-
Ash McKenzie authored
-
Ash McKenzie authored
-
Ash McKenzie authored
-
- Jul 05, 2022
-
-
Patrick Steinhardt authored
While gitlab-shell currently has a major version of v14, the module path it exposes is not using that major version like it is required by the Go standard. This makes it impossible for dependents to import gitlab-shell as a dependency without using a commit as version. Fix this by changing the module path of gitlab-shell to instead be `gitlab.com/gitlab-org/gitlab-shell/v14` and adjust all imports accordingly. Changelog: fixed
-
- Sep 30, 2021
-
-
Nick Thomas authored
-
- Sep 21, 2020
-
-
Stan Hu authored
Previously, gitlab-shell did not pass a context through the application. Correlation IDs were generated down the call stack instead of passed around from the start execution. This has several potential downsides: 1. It's easier for programming mistakes to be made in future that lead to multiple correlation IDs being generated for a single request. 2. Correlation IDs cannot be passed in from upstream requests 3. Other advantages of context passing, such as distributed tracing is not possible. This commit changes the behavior: 1. Extract the correlation ID from the environment at the start of the application. 2. If no correlation ID exists, generate a random one. 3. Pass the correlation ID to the GitLabNet API requests. This change also enables other clients of GitLabNet (e.g. Gitaly) to pass along the correlation ID in the internal API requests (https://gitlab.com/gitlab-org/gitaly/-/issues/2725). Fixes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/474
-
- Dec 03, 2019
-
-
Ash McKenzie authored
-
- Oct 18, 2019
-
-
Nick Thomas authored
-
Nick Thomas authored
-
- Jul 31, 2019
-
-
Patrick Bajao authored
Other functions are still expecting for `CommandArgs` instead of `Shell`. They should be expecting `commandargs.Shell` now since it has been renamed.
-
- Jun 06, 2019
-
-
Igor Drozdov authored
-