K6 is an open-source load testing tool designed for developers and testers in the DevOps era, primarily written in Go with JavaScript for test scripting. It is developed and maintained by Grafana.
The project has seen significant activity recently, with a strong focus on enhancing cloud-related features and improving performance monitoring. Notable developments include the introduction of a new 'k6 cloud upload' functionality, implementation of local execution mode for cloud runs, and integration of pyroscope traces for enhanced performance analysis. The team is also working on deprecating older authentication methods and refining the release process.
Recent issues and pull requests indicate a concerted effort to improve browser testing capabilities, optimize resource usage for large-scale tests, and enhance API functionality. The proposal to add native ESM support (#3265) stands out as a potentially significant enhancement to k6's JavaScript capabilities.
The development team has been particularly active:
Oleg Bespalov (olegbespalov): Recently updated the Sobek dependency with BigInt support and upgraded gRPC to v1.65.0. Currently working on async invoke for gRPC.
Ivan (codebien): Implemented a new release flow branching strategy and is working on telemetry improvements for test run IDs.
Joan López de la Franca Beltran (joanlopez): Introduced the 'k6 cloud upload' functionality and is working on deprecating email & password login for k6 cloud.
Théo Crevon (oleiade): Implementing local execution mode for k6 cloud run and adding pyroscope traces to the kontext module.
Mihail Stoykov (mstoykov): Fixed line number issues with inline sourcemaps and is working on making setTimeout and related functions globally available.
The introduction of 'k6 cloud upload' functionality (#3906) represents a significant shift in cloud integration strategy.
The implementation of local execution mode for k6 cloud run (#3904) enhances flexibility for users transitioning between local and cloud environments.
The ongoing work to add native ESM support (#3265) could substantially improve the JavaScript scripting experience for users.
The project is actively deprecating experimental features, indicating a move towards a more stable and streamlined codebase.
The introduction of a new release flow branching strategy suggests a maturing development process, potentially leading to more structured and predictable releases.
| Timespan | Opened | Closed | Comments | Labeled | Milestones |
|---|---|---|---|---|---|
| 7 Days | 2 | 1 | 0 | 0 | 1 |
| 30 Days | 12 | 9 | 10 | 1 | 2 |
| 90 Days | 51 | 36 | 85 | 3 | 4 |
| 1 Year | 174 | 134 | 397 | 16 | 8 |
| All Time | 1796 | 1436 | - | - | - |
Like all software activity quantification, these numbers are imperfect but sometimes useful. Comments, Labels, and Milestones refer to those issues opened in the timespan in question.
| Developer | Avatar | Branches | PRs | Commits | Files | Changes |
|---|---|---|---|---|---|---|
| Théo Crevon |  |
4 | 2/1/1 | 18 | 95 | 15152 |
| Oleg Bespalov |  |
4 | 4/2/0 | 8 | 126 | 2792 |
| Mihail Stoykov |  |
1 | 9/9/1 | 9 | 54 | 1438 |
| Federico Tedin |  |
1 | 0/0/0 | 5 | 5 | 1020 |
| Joan López de la Franca Beltran |  |
3 | 4/2/3 | 5 | 5 | 353 |
| Lev Zakharov |  |
1 | 1/1/0 | 1 | 6 | 178 |
| Ankur |  |
2 | 2/2/0 | 2 | 12 | 153 |
| Ivan |  |
3 | 3/1/0 | 3 | 5 | 146 |
| Dhia Abbassi (d14c) | 1 | 1/1/0 | 2 | 2 | 40 | |
| dependabot[bot] |  |
1 | 1/1/0 | 1 | 3 | 8 |
| Ben Radler |  |
1 | 0/1/0 | 1 | 1 | 1 |
| None (aiwaters) | 0 | 0/0/1 | 0 | 0 | 0 | |
| tsukasa-ino (tsukasaI) | 0 | 1/0/0 | 0 | 0 | 0 | |
| Ikko Eltociear Ashimine (eltociear) | 0 | 1/0/0 | 0 | 0 | 0 | |
| Athish Venkatesh (athishaves) | 0 | 1/0/0 | 0 | 0 | 0 |
PRs: created by that dev and opened/merged/closed-unmerged during the period
Based on the information provided, here is a high-level analysis of the recent GitHub issues activity for the k6 project:
Recent Activity Analysis:
There has been consistent activity on k6 GitHub issues over the past few months, with a mix of bug reports, feature requests, and general questions from users. Many issues are being actively triaged, discussed, and resolved by the k6 team.
Some notable themes and patterns in recent issues:
Browser testing: There are ongoing efforts to improve and stabilize k6's browser testing capabilities, including issues around configuration and performance (e.g. #3310, #3778).
Performance and resource usage: Several issues relate to optimizing k6's performance and resource consumption, especially for large-scale tests (e.g. #3515, #3518).
API enhancements: Users are requesting various API improvements and additions, such as support for WebSockets, Redis clusters, and file system operations (e.g. #3280, #3031, #3141).
Output and metrics: There are ongoing discussions about improving metrics output, especially for cloud integrations and time series databases (e.g. #3637, #3862).
JavaScript compatibility: Issues around JavaScript feature support and compatibility continue to arise as k6 evolves its JS engine (e.g. #3329, #3265).
Configuration and usability: Users are seeking ways to make k6 more flexible in terms of configuration and easier to use in various environments (e.g. #3362, #3682).
One particularly significant issue is #3265, which proposes adding native ESM (ECMAScript Modules) support to k6. This would be a major enhancement to k6's JavaScript capabilities and could simplify many aspects of test script development.
Issue Details:
Most recently created issues: 1. #3914: "k6 release v0.5x.0" (open, created 1 day ago) 2. #3907: "Make metrics.Metric be immutable" (open, created 3 days ago) 3. #3896: "k6 release v0.54.0" (open, created 11 days ago)
Most recently updated issues: 1. #3914: "k6 release v0.5x.0" (open, updated 1 day ago) 2. #3907: "Make metrics.Metric be immutable" (open, updated 3 days ago) 3. #3896: "k6 release v0.54.0" (open, updated 4 days ago)
These recent issues focus on upcoming releases and internal improvements to the metrics system. The release-related issues (#3914 and #3896) are particularly important as they coordinate the efforts for future versions of k6.
Here is a high-level summary of the key pull requests and development activity for the k6 project:
The pull request data shows very active ongoing development of k6, with 28 open pull requests and over 2000 closed pull requests. Recent work has focused on adding new features, improving existing functionality, and updating dependencies.
The pull requests show k6 is continuing to expand its capabilities, particularly around cloud execution, distributed testing, and support for additional protocols like gRPC. There's ongoing work to improve the developer experience through better error reporting and new APIs like the CSV parser.
Performance and scalability also seem to be key focus areas, with work on HDR histograms and optimizations for handling large responses. The project is maintaining compatibility while adding new features, as seen in the careful deprecation of older APIs.
Dependency management is actively maintained, with regular updates to key libraries. The release process is being refined to use release branches, indicating a maturation of the development workflow.
There are some larger refactoring efforts underway, like the metric type changes, which suggest the maintainers are working to improve the internal architecture as the project grows. The proof-of-concept work on test suites hints at potential major new features on the horizon.
Overall, the pull request activity demonstrates k6 is in active development with a good balance of new features, optimizations, and maintenance work. The project appears to be growing in sophistication while maintaining backward compatibility and stability.
Based on the recent commits and developer activity in the k6 project, here is a summary of the development team's recent activities:
Oleg Bespalov (olegbespalov):
Ivan (codebien):
Joan López de la Franca Beltran (joanlopez):
Théo Crevon (oleiade):
Ankur (ankur22):
Mihail Stoykov (mstoykov):
Iván Szkiba (szkiba):
Lev Zakharov (lzakharov):
Cloud Integration: There's a significant focus on improving and refining cloud-related features, including new subcommands, local execution modes, and login processes.
Performance and Telemetry: Work is being done to improve performance monitoring and data collection, such as integrating pyroscope traces and collecting test run IDs.
Dependency Updates: Regular updates to key dependencies like gRPC, Sobek, and various experimental modules.
Feature Deprecation and Cleanup: Efforts to remove or deprecate experimental or outdated features to streamline the codebase.
Browser and gRPC Improvements: Ongoing work to enhance browser testing capabilities and gRPC client functionality.
Release Management: Implementation of new release strategies and thorough release note preparation.
Code Quality and Testing: Continuous efforts to improve error handling, fix bugs, and enhance test coverage.
The team appears to be actively working on both new features and maintenance tasks, with a strong focus on cloud integration, performance, and code quality. There's also an emphasis on gradually phasing out experimental features as the project matures.
Who's most at risk of burnout among the contributors?
While the provided datasets don't contain specific information on individual contributor burnout risk, we can analyze recent activity and responsibilities to identify potential areas of concern.
Context:
Analysis:
Mihail Stoykov (mstoykov): Mihail has been incredibly active, contributing to numerous issues and pull requests, including significant refactoring and feature implementations (e.g., native ESM support, gRPC improvements, dropping legacy features). This heavy involvement in core functionalities and simultaneous work on multiple complex issues, including breaking changes, might indicate a potential risk of burnout.
Joan López de la Franca Beltran (joanlopez): Joan has been heavily involved in cloud integration, particularly with the 'k6 cloud upload' functionality and deprecating older authentication methods. This focused responsibility in a critical area, coupled with the pressure of potentially breaking changes, could contribute to stress.
Other contributors: While other contributors like Oleg Bespalov and Théo Crevon are also active, their work seems more focused on specific areas like dependency updates, bug fixes, and a new experimental module (kontext). This focused responsibility might imply a less intense workload compared to Mihail's broad involvement in core changes.
Citations:
Recommendations:
Disclaimer: This analysis is based on limited information and focuses on potential risk factors. It is not a definitive assessment of individual burnout. A more comprehensive evaluation would require direct input from contributors regarding their workload, stress levels, and support needs.
Tell me more about the new 'k6 cloud upload' functionality.
The new k6 cloud upload functionality is a subcommand introduced in k6 v0.53.0 to replace the deprecated k6 cloud --upload-only flag. It provides a dedicated way to upload test scripts or archives to Grafana Cloud k6 without immediately running them.
This separation of concerns enhances user experience and aligns with the broader initiative of revamping k6 cloud commands for improved clarity and organization.
Here's a breakdown of its significance:
Context:
Summary
Quantified Reports
Detailed Reports
Followup Questions--upload-only flag with the k6 cloud command. This approach lacked clarity and felt cumbersome.Analysis:
k6 cloud upload provides a clear and dedicated way to upload tests, separating the upload action from the run action.k6 cloud upload, further enhancing its utility.Citations:
k6 cloud upload: #3906This new functionality contributes to a more organized and user-friendly experience when working with Grafana Cloud k6, particularly for users who want to manage their test scripts or archives without immediately triggering test runs.