Slash commands in Mattermost and Slack allow you to control GitLab and view GitLab content right inside your chat client, without having to leave it. For Slack, this requires a [project service configuration](../user/project/integrations/slack_slash_commands.md). Simply type the command as a message in your chat client to activate it.
Commands are scoped to a project, with a trigger term that is specified during configuration. (We suggest you use the project name as the trigger term for simplicty and clarity.) Taking the trigger term as `project-name`, the commands are:
Commands are scoped to a project, with a trigger term that is specified during configuration.
We suggest you use the project name as the trigger term for simplicity and clarity.
Taking the trigger term as `project-name`, the commands are:
| Command | Effect |
...
...
@@ -12,3 +16,18 @@ Commands are scoped to a project, with a trigger term that is specified during c
| `/project-name issue show <id>` | Shows the issue with id `<id>` |
| `/project-name issue search <query>` | Shows up to 5 issues matching `<query>` |
| `/project-name deploy <from> to <to>` | Deploy from the `<from>` environment to the `<to>` environment |
## Issue commands
It is possible to create new issue, display issue details and search up to 5 issues.
## Deploy command
In order to deploy to an environment, GitLab will try to find a deployment
manual action in the pipeline.
If there is only one action for a given environment, it is going to be triggered.
If there is more than one action defined, GitLab will try to find an action
which name equals the environment name we want to deploy to.
Command will return an error when no matching action has been found.
your codebase, use it as an issue tracker, collaborate on code, and continuously
build, test, and deploy your app with built-in GitLab CI/CD.
Your projects can be [available](../../public_access/public_access.md)
publicly, internally, or privately, at your choice. GitLab does not limit
the number of private projects you create.
## Project's features
When you create a project in GitLab, you'll have access to a large number of
[features](https://about.gitlab.com/features/):
**Issues and merge requests:**
-[Issue tracker](issues/index.md): Discuss implementations with your team within issues
-[Issue Boards](issue_board.md): Organize and prioritize your workflow
-[Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards)(**EES/EEP**): Allow your teams to create their own workflows (Issue Boards) for the same project
-[Repositories](repository/index.md): Host your code in a fully
-[Pipeline settings](pipelines/settings.md): Set up Git strategy (choose the default way your repository is fetched from GitLab in a job),
timeout (defines the maximum amount of time in minutes that a job is able run), custom path for `.gitlab-ci.yml`, test coverage parsing, pipeline's visibility, and much more
-[GitLab Pages](pages/index.md): Build, test, and deploy your static
website with GitLab Pages
**Other features:**
-[Cycle Analytics](cycle_analytics.md): Review your development lifecycle
-[Koding integration](koding.md)(not available on GitLab.com): Integrate
with Koding to have access to a web terminal right from the GitLab UI
-[Syntax highlighting](highlighting.md): An alternative to customize
your code blocks, overriding GitLab's default choice of language
### Project's integrations
[Integrate your project](integrations/index.md) with Jira, Mattermost,
Kubernetes, Slack, and a lot more.
## New project
Learn how to [create a new project](../../gitlab-basics/create-project.md) in GitLab.
### Fork a project
You can [fork a project](../../gitlab-basics/fork-project.md) in order to:
- Collaborate on code by forking a project and creating a merge request
from your fork to the upstream project
- Fork a sample project to work on the top of that
## Import or export a project
- Import a project from:
-[GitHub to GitLab](../../workflow/importing/import_projects_from_github.md)
-[BitBucket to GitLab](../../workflow/importing/import_projects_from_bitbucket.md)
-[Gitea to GitLab](../../workflow/importing/import_projects_from_gitea.md)
-[FogBugz to GitLab](../../workflow/importing/import_projects_from_fogbugz.md)
-[Export a project from GitLab](settings/import_export.md#exporting-a-project-and-its-data)
-[Importing and exporting projects between GitLab instances](settings/import_export.md)
## Leave a project
**Leave project** will only display on the project's dashboard
when a project is part of a group (under a
[group namespace](../group/index.md#namespaces)).
If you choose to leave a project you will no longer be a project
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12621) in GitLab 9.4
GitLab has support for automatically detecting and monitoring HA Proxy. This is provided by leveraging the [HA Proxy Exporter](https://github.com/hnlq715/nginx-vts-exporter), which translates HA Proxy statistics into a Prometheus readable form.
GitLab has support for automatically detecting and monitoring HAProxy. This is provided by leveraging the [HAProxy Exporter](https://github.com/prometheus/haproxy_exporter), which translates HAProxy statistics into a Prometheus readable form.
## Metrics supported
...
...
@@ -10,9 +10,9 @@ GitLab has support for automatically detecting and monitoring HA Proxy. This is
## Configuring Prometheus to monitor for HAProxy metrics
## Configuring Prometheus to monitor for HAProxy metrics
To get started with NGINX monitoring, you should install and configure the [HAProxy exporter](https://github.com/prometheus/haproxy_exporter) which parses these statistics and translates them into a Prometheus monitoring endpoint.
To get started with NGINX monitoring, you should install and configure the [HAProxy exporter](https://github.com/prometheus/haproxy_exporter) which parses these statistics and translates them into a Prometheus monitoring endpoint.
GitLab offers automatic detection of select [Prometheus exporters](https://prometheus.io/docs/instrumenting/exporters/). Currently supported exporters are:
*[Kubernetes](kubernetes.md)
*[NGINX](nginx.md)
*[HAProxy](haproxy.md)
*[HAProxy](haproxy.md)
*[Amazon Cloud Watch](cloudwatch.md)
We have tried to surface the most important metrics for each exporter, and will be continuing to add support for additional exporters in future releases. If you would like to add support for other official exporters, [contributions](#adding-to-the-library) are welcome.
@@ -91,7 +91,6 @@ This workflow where commits only flow downstream ensures that everything has bee
If you need to cherry-pick a commit with a hotfix it is common to develop it on a feature branch and merge it into master with a merge request, do not delete the feature branch.
If master is good to go (it should be if you are practicing [continuous delivery](http://martinfowler.com/bliki/ContinuousDelivery.html)) you then merge it to the other branches.
If this is not possible because more manual testing is required you can send merge requests from the feature branch to the downstream branches.
An 'extreme' version of environment branches are setting up an environment for each feature branch as done by [Teatro](https://teatro.io/).