Gitlab monitor

Gitlab monitor DEFAULT

Monitor Group

  1. You are here:
  2. Engineering
  3. Development Department
  4. Ops Sub-department
  5. Monitor Stage
  6. Monitor Group

On this page

Monitor

The Monitor group at GitLab is responsible for building tools that enable DevOps teams to respond to, triage and remediate errors and IT alerts for the systems and applications they maintain. We aim to provide a streamlined Operations experience within GitLab that enables the individuals who write the code, to maintain it at the same time.

Exciting things and accomplishments

This section details the happenings within the Monitor group. At any given time this section will have the top exiciting things and/or accomplishments of the team.

  1. On-Call Schedules and Escalation Policies are available!
  2. The Infrastructure team is Dogfooding the incident issue type!

Peformance Indicators

The Monitor Group’s mission is to decrease the frequency and severity of incidents. By helping our users respond to alerts and incidents with a streamlined workflow, and capturing useful artifacts for feedback and improvement, we can accomplish our mission. To get started, we need to establish an initial user base that we can learn from to improve and further grow the Monitor stage. We have prioritized the Incident Management category to obtain this usage.

With that in mind, our primary performance indicator, the Monitor SMAU, is the count of unique users that interact with alerts and incidents. This PI will inform us if we are on the right path to provide meaningful incident response tools.

We expect to track the journey of users through the following funnel:

classDiagram Acquisition --|> Activation Acquisition: Are users aware of the product or feature set? Acquisition: Measurement (Count of views of alerts list and incident list) Activation --|> Retention Activation: Are users applying the feature? Activation: Measurement (Count of monthly active users leveraging alerts (Alert MAU)) Retention --|> Revenue Retention: Are users applying the feature over time? Retention: Measurement (Count of monthly active users leveraging incidents (Incident MAU)) Revenue --|> Referral Revenue: Are users paying for the features? Revenue: Measurement (Count of monthly active users leveraging paid features (Alert endpoints, on-call schedule management, Status Page, etc)) Referral --|> Acquistion Referral: Are users encouraging others to use the feature? Referral: Measurement (In App referrals for setting up alert and incident management in other projects)

PI Dashboards

  • Monitor error budget dashboard: The Monitor Group has work in progress to separate our dashboard into two, active and inactive projects. This will allow the team to identify trends in our newly released features separately from inactive projects. We're looking for different trends in active vs inactive projects. Active projects are constantly changing and the chances of introducing problems that impact our Error Budget are more likely. With inactive projects, we're looking for impact from changes in dependencies which may adversely affect the Error Budget. The team will review both of the dashboards monthly as part of our async retrospective process and track the needed improvements as technical debt issues.

Snowplow Events

Please view this sisense chart for a list of events we have instrumented for Monitor categories.

Communication

Team members

Stable counterparts

PersonRole
Alana BellucciSenior Product Manager, Monitor
Amelia BauerlySenior Product Designer, Monitor:Monitor
Nick GaskillSenior Technical Writer, Package, Monitor, Protect
Vitor Meireles De SousaSenior Security Engineer, Application Security, Package (Package), Configure (Configure), Monitor (Monitor)
Justin MandellProduct Design Manager, Configure, Monitor, Secure & Protect
Kevin ChuGroup Manager of Product Management, Configure, Monitor, Release

Responsibilities

This team maps to the Monitor Group category and focuses on:

Working Agreements

🤝 Collaboration

  • Anything in an issue description is allowed to change. And YOU'RE allowed to do it. Since we have the description history, we can always go back to an old version with negligible effort. If making a substantial change to the description, provide some explanation to explain why it's changing. Issue descriptions are documentation, not a single person's opinion.
    • Related: try to keep “I”s out of the issues you write, or differentiate your personal opinions/context by adding a disclaimer/bold/italics. Personal opinions could also be added to the comments section so that others can respond and discuss them. If a description is less personal, it's easier for anyone else to feel like they can improve or refine it.
  • It's ok to ask people to do things directly. It may feel uncomfortable, but you have to trust that they can manage their own time and priorities.
    • "Someone should probably do X." is a trap. Prefer "Would anyone be willing to do X?" or "Who can take on X?". Identifying a specific owner for each new task or subtask (write tests, update docs, add a follow-up, etc) will prevent it from getting lost or forgotten.
  • Conversely, it's ok to say no or offer hard limits.
    • When you do say "no", propose alternatives or a potential path forward for that person to get what they want/need.

📈 Results

  • Just declare a plan. If people don't agree, they'll tell you.
    • If requirements are unclear, ask for help and explain exactly what you're looking for. Prefer questions like "What should happen in scenario X?" to "I'm not sure how Y should work." The responder should be able to tell whether they've unblocked you simply by making sure each of your questions has an answer.
    • If the discussion has gotten off-track, you can't tell what the action item should be, or you don't have an opinion yourself, make the plan up! Then communicate it.
  • It's also ok to express a direct opinion about what you think is best when presenting a set of options.
    • It's way easier to engage with your work if you believe in what you're building. Advocate for it.
  • Sometimes it’s necessary to accept risk to make progress.

⏱️ Efficiency

  • It's ok to say "I'm so confused, can you explain it differently?"
  • When answering questions or posing questions, always think "who is my audience, and what info do they need right now?"
    • Make it easy for the reader to just pick an option or take action.
    • If posing a question/problem to multiple groups, categorize information & label it. Let the reader choose what they want to read.
    • A question posed to a designer should be different from a question asked of an engineer. Our designer needs to know the impact of the decision on the user, how big of a pain a given solution is, or whether an option has implications for the design down the line. Conversely, an engineer needs to know which code is being discussed, any implicit assumptions that have been made, which requirements are already known, or why certain options have been ruled out. But in either circumstance, you want to provide the responder with exactly what they need to make an informed choice by the time they reach the end of the question/comment.

🌐 Diversity, Inclusion & Belonging

  • Communication is hard. Our attention spans are short. If possible, supplement with pictures.
    • If you are verbose, that's ok. Include summaries, tldrs, tables, headers, and style your text to make it easier to consume your writing.

👣 Iteration

  • If you already took an action down one path, but now you need to go a different direction, that's ok. That's iteration. You did not waste time or do anything wrong. You just moved forward.

👁️ Transparency

  • If there's 80% of a decision but still some unknowns, it can be ok to use "I'm just going to improvise" as the plan for the remaining pieces. Just state it explicitly in advance & communicate the outcome afterward.
    • The best path forward is sometimes the path of least resistance. It often doesn't matter what you do, as long as it's well communicated.

Repos we own or use

  • Prometheus Ruby Mmap Client - The ruby Prometheus instrumentation lib we built, which we used to instrument GitLab
  • GitLab CE and GitLab EE - Where much of the user facing code lives
  • Omnibus and Charts, where a lot of the packaging related work goes on. (We ship GitLab fully instrumented along with a Prometheus instance)

Issue boards

  • Monitor - Planning - Main board with all issues scoped to label "group::monitor"
  • Monitor - Workflow - Issue board organized by workflow labels
  • Charts - Issue board with all issues labeled "Charts"
  • Monitor Bugs - Issue board organized by Priority labels so that we make sure we meet our bug fix SLA

Experiments

Issue refinement process

Note: Started in 13.1 milestone.

Context

It is pretty common for issues that were assigned and/or picked up by engineer(s) to have the label but not be actionable or ready for development. Sometimes, this is because the scope of the issue is unclear or follow up questions and answers are needed in order to get started. Depending on an engineer(s) timezone relative to other team members (with answers to the questions), an issue could take several working days before an engineer is able to start working on the issue. This additional "waiting time" before being able to start on an issue can be inefficient; especially in the beginning of the milestone. This is because there are more issues assigned and/or picked up in the beginning of a milestone which creates a bottleneck before development can begin. We call this "waiting time", issue refinement.

Hypothesis

By distributing the work of refining issues to a point where issues are actionable when the label is set throughout the milestone we can become more efficient with engineer(s) development time, which will lead to higher MR rate.

Process

For this experiment, we will have a new column on our current milestone issue board called . Engineering manager(s) will work with the PM to determine which issues should be placed in that column. Engineer(s) are expected to refine 1-2 issues per milestone.

When an engineer is ready to refine an issue, the engineer should:

  1. Assign themselves to the issue
  2. Refine the issue. Ask clarify questions. Make the issue truly actionable when the next engineer picks up the issue.
    1. If an issue's scope is too big, consider promoting the issue into an epic and create issues for each iteration (and link the issues back to the epic)
  3. After an issue (or the broken down issues) are actionable:
    1. Change the workflow label to
    2. Add the label
    3. Change the milestone of the issue to
    4. Unassign themselves

Development Processes

Surfacing blockers

To surface blockers, mention your Engineering Manager in the issues, and then contact them via slack and or 1:1's. Also make sure to raise any blockers in your daily async standup using Geekbot.

The engineering managers want to make unblocking their teams their highest priority. Please don't hesitate to raise blockers

Scheduling

Scheduling issues in milestones

The Product Manager is responsible for scheduling issues in a given milestone. During the backlog refinement portion of our weekly meeting, all parties will make sure that issues are scoped and well-defined enough to implement and whether they need UX involvement and/or technical investigation.

As we approach the start of the milestone, Engineering Managers are responsible for adding the ~deliverable label to communicate which issues we are committing to finish in the given milestone. Generally, the Engineering Manager will use the prioritized order of issues in the milestone to determine which issues to label as ~deliverable. The Product Manager will have follow-up conversations with the Engineering Managers if the deliverables do not meet their expectations or if there are other tradeoffs we should make.

Estimating

We use the following values for estimating the effort of issues to help determine our capacity during the planning process.

  • XS: 1 to 2 days to merge
  • S: 2 days to a week to merge
  • M: 1 to 2 weeks to merge
  • L: 2 weeks to 1 cycle to merge
  • XL: Bigger than 1 cycle (needs to be broken down further)

Scheduling bugs

When new bugs are reported, the engineering managers ensure that they have proper Priority and Severity labels. Bugs are discussed during backlog refinement session and are scheduled according to severity, priority, and the capacity of the teams. Ideally, we should work on a few bugs each release regardless of priority or severity.

Scheduling technical debt

As new technical debt issues are created, the engineering manager and product manager will triage, prioritize and schedule these issues on a weekly basis using the Monitor - Tech Debt board. Issues with a P1 or P2 will be scheduled during milestone planning. When new issues are created by Monitor team members, add any relevant context to the description about the priority or timing of the issue, as this will help streamline the triage work.

Priorities for scheduling technical debt will apply as follows:

  • P1: Interrupt the current milestone or schedule in the next milestone
  • P2: Schedule in the next 1-2 milestones
  • P3: To be scheduled at a later date
  • P4: Backlog, awaiting higher demand

Weekly async issue updates

Every Friday, each engineer is expected to provide a quick async issue update by commenting on their assigned issues using the following template:

We do this to encourage our team to be more async in collaboration and to allow the community and other team members to know the progress of issues that we are actively working on.

Interacting with community contributors

Community contributions are encouraged and prioritized at GitLab. Please check out the Contribute page on our website for guidelines on contributing to GitLab overall.

Within the Monitor stage, Product Management will assist a community member with questions regarding priority and scope. If a community member has technical questions on implementation, Engineering Managers will connect them with engineers within the team to collaborate with.

Using spikes to inform design decisions

Engineers use spikes to conduct research, prototyping, and investigation to gain knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate (paraphrased from this overview). When we identify the need for a spike for a given issue, we will create a new issue, conduct the spike, and document the findings in the spike issue. We then link to the spike and summarize the key decisions in the original issue.

Assigning MRs for code review

Engineers should typically ignore the suggestion from Dangerbot's Reviewer Roulette and assign their MRs to be reviewed by a frontend engineer or backend engineer from the Monitor stage. If the MR has domain specific knowledge to another team or a person outside of the Monitor Stage, the author should assign their MR to be reviewed by an appropriate domain expert. The MR author should use the Reviewer Roulette suggestion when assigning the MR to a maintainer.

Advantages of keeping most MR reviews inside the Monitor Stage include:

  • Quicker reviews because the reviewers hopefully already have the context and don't need additional research to figure out how the MR is supposed to work.
  • Knowledge sharing among the engineers in the Monitor Stage. There is a lot of overlap between the groups in the stage and this effort will help engineers maintain context and consistency.

Preparing UX designs for engineering

Product designers generally try to work one milestone ahead of the engineers, to ensure scope is defined and agreed upon before engineering starts work. So, for example, if engineering is planning on getting started on an issue in 12.2, designers will assign themselves the appropriate issues during 12.1, making sure everything is ready to go before 12.2 starts.

To make sure this happens, early planning is necessary. In the example above, for instance, we'd need to know by the end of 12.0 what will be needed for 12.2 so that we can work on it during 12.1. This takes a lot of coordination between UX and the PMs. We can (and often do) try to pick up smaller things as they come up and in cases where priorities change. But, generally, we have a set of assigned tasks for each milestone in place by the time the milestone starts so anything we take on will be in addition to those existing tasks and dependent on additional capacity.

The current workflow:

  • Though Product Designers make an effort to keep an eye on all issues being worked on, PMs add the UX label to specific issues needing UX input for upcoming milestones.

  • The week before the milestone starts, the Product Designers divide up issues depending on interest, expertise and capacity.

  • Product Designers start work on assigned issues when the milestone starts. We make an effort to start conversations early and to have them often. We collaborate closely with PMs and engineers to make sure that the proposed designs are feasible.

  • In terms of what we deliver: we will provide what's needed to move forward, which may or may not include a high-fidelity design spec. Depending on requirements, a text summary of the expected scope, a balsamiq sketch, a screengrab or a higher fidelity measure spec may be provided.

  • When we feel like we've achieved a 70% level of confidence that we're aligned on the way forward, we change the label to ~'workflow::ready for development' as a sign that the issue is appropriately scoped and ready for engineering.

  • We usually stay assigned to issues after they are ~'workflow::ready for development' to continue to answer questions while the development process is taking place.

  • Finally, we review MRs following the guidelines as closely as possible to reduce the impact on velocity whilst maintaining quality.

Repos we own or use

  • Prometheus Ruby Mmap Client - The ruby Prometheus instrumentation lib we built, which we used to instrument GitLab
  • GitLab CE and GitLab EE - Where much of the user facing code lives
  • Omnibus and Charts, where a lot of the packaging related work goes on. (We ship GitLab fully instrumented along with a Prometheus instance)

Service accounts we own or use

Zoom sandbox account

In order to develop and test Zoom features for the integration with GitLab we now have our own Zoom sandbox account.

Requesting access

To request access to this Zoom sandbox account please open an issue providing your non-GitLab email address (which can already be associated an existing non-GitLab Zoom account).

The following people are owners of this account and can grant access to other GitLab Team Members:

Granting access

  1. Log in to Zoom with your non-GitLab email
  2. Go to User Management > Users
  3. Click on
  4. Specify email addresses
  5. Choose - most likely
  6. Click - the users receive invitations via email
  7. Add the linked name to the list in "Requesting access"

Documentation

For more information on how to use Zoom see theirs guides and API reference.

Recurring Meetings

While we try to keep our process pretty light on meetings, we do hold a Monitor:Monitor Backlog Refinement meeting weekly to triage and prioritize new issues, discuss our upcoming issues, and uncover any unknowns.

Labels

The Monitor team uses labels for issue tracking and to organize issue boards. Many of the labels we use also drive reporting for Product Management and Engineering Leadership to track delivery metrics. It's important that labels be applied correctly to each issue so that information is easily discoverable.

Issue Labels

LabelRequiredDescription
StageYesIdentifies which stage of GitLab an issue is assigned to.
GroupYesIdentifies which team this issue belongs to. This triggers new issues to appear in the weekly triage report for the team's Product and Engineering managers.
TeamYesIdentifies which team (or both) will develop a solution.
CategoryNoIdentifies the correct Monitor category the issue falls under.
Milestone%#.##NoWhile technically not a label, if the issue is being worked on immediately, add the current milestone. If you know when the issue needs to be scheduled (such as follow-up work), add the future milestone that it should be scheduled in. Otherwise, leave it empty.
PriorityYes, when scheduledIf an issue is scheduled in the current milestone it mush have a or label.
Issues committed to being completed in the current milestone.
Issues which are not committed in the current milestone. These are typically either stretch goals, technical debt or non-customer facing.
Issue TypeYes
Feature Issues
Bug Issues
Technical Debt
WorkflowYes
Issues that need further input from team members in order for it to be .
Waiting on external factors or another issue to be completed before work can resume.
The issue is refined and ready to be scheduled in a current or future milestone.
Issues that are actively being worked on by a developer.
Issues that are undergoing code review by the development team.
Everything has been merged, waiting for verification after a deploy.

Deliverable Labels

In our group, the (frontend + backend) engineering managers are responsible for adding the label to any issues that the team is publicly stating that to the best of their ability, they expect that issue to be completed in that milestone. We are not perfect but our goal is that 100% of the issues with that label do ship in the release that they are scheduled in. This allows engineering to share what issues they commit to and helps set expectations for the product manager and for the community.

Monitor Stage PTO

Just like the rest of the company, we use PTO by Roots to track when team members are traveling, attending conferences, and taking time off. The easiest way to see who has upcoming PTO is to run the command in the slack channel. This will show you the upcoming PTO for everyone in that channel.

Reading list

A list of interesting content related to the areas of the Monitor stage product.

Sours: https://about.gitlab.com/handbook/engineering/development/ops/monitor/monitor/

GitLab's DevOps platform empowers 100,000+ organizations to deliver software faster and more efficiently. We are one of the world’s largest all-remote companies with 1,400+ team members and values that guide a culture where people embrace the belief that everyone can contribute.

GitLab is looking for a Backend Engineer for the Monitor Stage who will focus on building our Incident Management and Alerting functionality. In this role you will develop features to support infrastructure and software teams as they respond to incidents and outages.  

The Monitor Stage works closely with infrastructure teams to understand what information they need at their fingertips to respond quickly and resolve incidents. A large portion of our work consists of developing new features.  If you have experience as an SRE or have worked closely with SREs, you’ll have opportunities to influence the way our product works.

Responsibilities:

  • Develop features and improvements to the GitLab product in a secure, well-tested, and performant way.
  • Collaborate with Product Management, Product Designers, Frontend Engineers and other stakeholders to maintain a high bar for quality in a fast-paced, iterative environment.
  • Advocate for improvements to product quality, security, and performance.
  • Solve technical problems of moderate scope and complexity.
  • Craft code that meets our internal standards for style, maintainability, and best practices for a high-scale web environment. Maintain and advocate for these standards through code review.
  • Recognize impediments to our efficiency as a team, and propose and implement solutions.
  • Ship small features and improvements with minimal guidance and support from other team members. Collaborate with the team on larger projects.

You should apply if you bring:

  • Professional experience with Ruby on Rails and GraphQL.
  • Proficiency in the English language, both written and verbal, sufficient for success in a remote and largely asynchronous work environment.
  • Demonstrated capacity to clearly and concisely communicate about complex technical, architectural, and/or organizational problems and propose thorough iterative solutions.
  • Comfort working in a highly agile, intensely iterative software development process.
  • Demonstrated ability to onboard and integrate with an organization long-term.
  • Positive and solution-oriented mindset.
  • Effective communication skills: Regularly achieve consensus with peers, and clear status updates.
  • Aspiration toward building our culture of communication, inclusion, and visibility.
  • Experience owning a project from concept to production, including proposal, discussion, and execution.
  • Self-motivated and self-managing, with strong organizational skills.
  • Demonstrated ability to work closely with other parts of an organization.
  • Share our values, and work in accordance with those values.

You'll stand out if you bring:

  • Experience with Site Reliability Engineering.
  • Experience with VueJS or other modern Javascript frameworks.
  • Experience with the GitLab product as a user or contributor.
  • Experience with database scaling.

Also, we know it's tough, but please try to avoid the confidence gap. You don't have to match all the listed requirements exactly to be considered for this role.

Hiring Process

  • Our hiring process for this Backend Engineer position typically follows four stages. The details of this process can be foundon our job family page.

Additional details about our process can be found on our hiring page.

Country Hiring Guidelines

GitLab hires new team members in countries around the world. All of our roles are remote, however some roles may carry specific location-based eligibility requirements. Our Talent Acquisition team can help answer any questions about location after starting the recruiting process.  


Your Privacy

For information about our privacy practices in the recruitment process, please visit our Recruitment Privacy Policy page.

Sours: https://boards.greenhouse.io/gitlab/jobs/5352023002
  1. Bulk grains online
  2. Rhea county schools
  3. Galveston isd teacher salary
  4. Anoka co library

GitLab CI Monitor

A simple dashboard for monitoring GitLab CI builds. Alpha version.

Gitlab Support: 9.0 (API V4)

Example

Usage

This project runs completely in the browser. It expects a few parameters in the query string:

  • gitlab: your gitlab server address (not needed if you deployed the monitor on the gitlab instance)
  • token: your gitlab token (if you deployed the monitor on the gitlab instance you may set this to )
  • projects: a comma separated list of projects in the form GROUP_NAME/PROJECT_NAME/BRANCH_NAME you want to monitor.
  • groups: a comma separated list of groups or subgroups
  • order: a comma separated list of fields to order projects, optionally followed by .asc or .desc modifier

At least one of or need to be set.

Example:

With these parameters, it will try to fetch the list of projects that this token has access. Then, it will filter the list by the projects parameter and show only the ones that have builds (i.e., that have GitLab CI enabled).

If you set it will show the status of the default branch of those projects in the group, which are active and have jobs enabled.

Example:

This requires installation on the gitlab server. With these parameters you see the pipeline state of the default branch of all projects in groups group1, base/group2 and group3.

  • The project name in title of a box links to the project, the branch name to the tree view of the branch.
  • The commit hash on the lower left links to the tree view of the commit.
  • The commit title links to the pipeline overview.
  • Hovering over the time on the lower right will give you the exact date.

Installation on a GitLab instance

  • Download and unpack to a directory of your choice:

or

  • Now insert the following to your (the entry already exists but it commented):
  • Run
  • Now you may use the monitor without providing the parameter and set

License

GitLab CI Monitor is licensed under the MIT license.

Sours: https://github.com/globocom/gitlab-ci-monitor
GitLab Monitoring: Grafana Integration Setup n' Demo

Monitor

GitLab logo svg

Runbooks

Runbooks are a collection of documented procedures that explain how to carry out a particular process, be it starting, stopping, debugging, or troubleshooting a particular system. Executable runbooks allow operators to execute pre-written code blocks or database queries against a given environment.

Learn More →
GitLab logo svg

Metrics

GitLab collects and displays performance metrics for deployed apps, leveraging Prometheus. Developers can determine the impact of a merge and keep an eye on their production systems, without leaving GitLab.

Learn More →
GitLab logo svg

Incident Management

Track incidents within GitLab, providing a consolidated location to understand the who, what, when, and where of the incident. Define service level objectives and error budgets, to achieve the desired balance of velocity and stability.

Learn More →
GitLab logo svg

On-call Schedule Management

Track DevOps responsibilities within your team by creating rotating schedules for responders.

Learn More →
GitLab logo svg

Logging

GitLab makes it easy to view the logs distributed across multiple pods and services using log aggregation with Elastic Stack. Once Elastic Stack is enabled, you can view your aggregated Kubernetes logs across multiple services and infrastructure, go back in time, conduct infinite scroll, and search through your application logs from within the GitLab UI itself.

Learn More →
GitLab logo svg

Tracing

Tracing provides insight into the performance and health of a deployed application, tracking each function or microservice which handles a given request. This makes it easy to understand the end-to-end flow of a request, regardless of whether you are using a monolithic or distributed system.

Learn More →
GitLab logo svg

Error Tracking

Error tracking allows developers to easily discover and view the errors that their application may be generating. By surfacing error information where the code is being developed, efficiency and awareness can be increased.

Learn More →
Sours: https://about.gitlab.com/stages-devops-lifecycle/monitor/

Monitor gitlab

An abstract representation of an eye GitLab Monitor

A browser-based monitor dashboard for GitLab CI

Use & Download

Hosted version

Note: I recently changed the address from timoschwarzer.com/gitlab-monitor to gitlab-monitor.timoschwarzer.com! Please update your config if you still use the old address. Sorry for the inconvenience!

If you don't want to setup your own server, you can always use the latest version of GitLab Monitor I upload here:

https://gitlab-monitor.timoschwarzer.com/

Don't worry, I don't save access tokens or anything else. Additionally, this version has a manifest.json attached which makes it easy to pin it to your Android home screen and open it as a full screen app.

Support me on Patreon

Docker

dockeri.co

There's an official docker image available on Dockerhub:

Host it yourself

Go to releases

Screenshots

Screenshot 1Screenshot 2

Build Setup

# install dependencies yarn install # serve with hot reload at localhost:8080 yarn run dev # build for production with minification yarn run build

Configuration

See configuration.

Used libraries

Visit my website!

Sours: https://github.com/timoschwarzer/gitlab-monitor
Monitor Stage Demo Hour 2019-09-06

.

Similar news:

.



58 59 60 61 62