library and tools for bug, issue, and ticket mangling
Library and tools for bug, issue, and ticket mangling.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Using the subcommands create, get, view, list, and update to differentiate between different attachment-related actions.
In general, I think it would be easiest if AND queries were specified by comma-separated values and OR queries by multiple option usage.
For example, bite s --cc user1,user2 would search for bugs with both user1 and user2 in the CC list while bite s --cc user1 --cc user2 would search for bugs with user1 or user2 in the CC list.
Bugzilla allows specifying flags for attachments so that should be supported during creation and updating.
Currently the man pages are built directly from clap's long_help content, but it might be preferable long term to write them externally (probably using asciidoc) so that custom content is easier to add and the related program binaries (when built in the default fashion) don't have to include all the doc-related text.
Having them external should also make it easier to generate different output formats from them including man pages, HTML, etc.
The clap-stdin supports this to an extent, but it doesn't appear to support pulling vectors of arguments which we require. However, its approach can probably be copied and extended.
Also to note, it's currently difficult to use custom containers beyond Vec for struct fields with clap so multi-arg stdin support parsing probably is easiest to do when the command is running and not internally by clap.
Basic issue creation should be supported as it is for bugzilla support.
Atm the gentoo bugzilla supports attachment with a maximum size of 1024kb.
Would be great if when the size of the attachment is greater than 1024kb (e.g. $BUGBITE_MAX_ATTACHMENT_SIZE variable), bite compress it and attachs it as compressed.
That should be done in presence of, for example, --auto-compress-attachment option.
This scenario has two possible way:
Atm, for compress logs I'm using xz, and I verified that it gives the best ratio compression. With the recent changes in xz, I'm using: xz -k -z -9 -T 1 -M 3000000000 "${BUILD_LOG}"
but I suppose that apart -z we can use something like $BUGBITE_XZ_OPTS
For example, via advanced searching attachment MIME types can be matched against.
It could be handy to have a test config available with connections defined for various local container instances used for testing.
It could be useful to be able to override the default compression type via config option without having to specify an explicit compression type in the related --compress <type> option for every call.
This would probably require collapsing the type argument to a enum value while running instead of internally via clap parsing since the config object wouldn't be available in that context.
As discussed in #34, sometimes log files being attached are too large even when compressed. In that case it would be nice to support auto-truncation to the last N lines of the file.
It would handy if the core library supported loading connection configuration for simple TOML files so user's can define their own connection aliases beyond the bundled ones that can be used by both the cli and tui tools.
It should be possible to serialize modification and creation requests and then later submit them.
This could be useful for several reasons, for example semi or fully automated testing that generates bug reports could cache changes and submit them all at once after a manual review or at other opportune times.
In addition, it would be possible to work offline on bugs and then push changes later. This would probably be more handy on the TUI side.
One possibility is manually writing extensions/plugins for certain bundled connections.
Another option is include support for a cached field mapping that can be automatically updated.
The main issue with displaying the fields is either the field names have to be hardcoded or they have to be pulled from a given service at some point, preferably done a single time and cached somehow.
Most services limit search requests to a set maximum amount of results and require paging requests to retrieve more.
Currently the output support is very rudimentary but it should be auto-modified when fields are requested.
It might also be interesting to support flattening vector types relating to IDs for output when they are the only field specified. This would allow for commands such as: bite s -c 1d -F depends-on | bite s --id - which would query for all open dependencies of bugs created in the last day. Alternatively the allowed input types for ID fields could be extended to allow CSV input which could be output in those situations.
It would be useful to simplify bug creation in native rust using a builder pattern similar to the following:
let id = service.create()
.summary("summary")
.component("Component")
.product("Product")
.description("description")
.await?;Switch to a different version of bumpalo to resolve this issue.
Values for options such as --id, --blocks, and --depends should be able to take ranges as well as values.
Currently bug creation support doesn't support setting flags.
It appears that vergen is currently one of the best solutions to do this.
Currently time deltas are used, e.g. 1d means 1 day ago, and it would be handy to also support static values such as 2024-03-24.
Unfortunately the REST API currently doesn't support this, but the older web service API variants do so it's probably easiest to use a JSON-RPC method for the specific call required.
Currently only bug IDs are supported.
Bugzilla supports updating attachment metadata for existing attachments which could probably be supported via -u/--update along with some option restrictions.
Another existing bug could be specified when creating a new one which would use its values for relevant, non-unique fields such as product, component, etc.
This would also support generating templates from existing bugs without actually creating a new bug when -n/--dry-run is used.
Currently just external files are used, but it could be interesting to support embedding templates into the main config file and loading them via aliases.
While much of the surface level testing can be done via mocked interactions, it would be useful to support conditional tests (enabled by a feature) that test against a local instance spun up inside a container.
When you file a bug, is very likely that you need the bug number to make further operations (attach logs, do more comments, cc people and so on).
So would be very useful that given a variable (like BUGBITE_CREATED_BUG), bite unsets it before file the bug and then fills it with the bug number if the creation succeded.
That should work only for creation, at least for bugzilla service.
This would require triggering another API call during deserialization to determine the status of a bug's blockers and dependencies. Bugzilla's web interface displays them using strike-through text, but on the CLI it would probably be better to use different colors so the IDs are easier to read.
A custom query grammar should be able to support logical operators, expressions, and grouping that it translates into the parameters Bugzilla expects.
Raw responses will probably be handy to use for simulating service support during unit tests so having a way to dump real responses from actual services could be useful.
| Details | |
|---|---|
| Package | rustls |
| Version | 0.22.3 |
| URL | GHSA-6g7w-8wpp-frhj |
| Patched Versions | >=0.23.5 OR >=0.22.4, <0.23.0 OR >=0.21.11, <0.22.0 |
| Aliases | GHSA-6g7w-8wpp-frhj |
If a close_notify alert is received during a handshake, complete_io
does not terminate.
Callers which do not call complete_io are not affected.
rustls-tokio and rustls-ffi do not call complete_io
and are not affected.
rustls::Stream and rustls::StreamOwned types use
complete_io and are affected.
| Details | |
|---|---|
| Package | h2 |
| Version | 0.4.3 |
| URL | n/a |
| Patched Versions | ^0.3.26 OR >=0.4.4 |
An attacker can send a flood of CONTINUATION frames, causing h2 to process them indefinitely.
This results in an increase in CPU usage.
Tokio task budget helps prevent this from a complete denial-of-service, as the server can still
respond to legitimate requests, albeit with increased latency.
More details at "https://seanmonstar.com/blog/hyper-http2-continuation-flood/.
Patches available for 0.4.x and 0.3.x versions.
Manually writing changelogs for releases can be annoyingly painful so it might be worth altering/marking up commits so they can be automatically generated instead using git-cliff.
It could be useful to cache search results per configured connection (and keyed via ID) that can then be use for auto-completion for the get subcommand.
For various parameters that support datetime ranges, it would be handy to support parsing rust-like ranges using datetime shorthand such as 1w..1d or 1d.. in addition to more specific values. This should probably be implemented in the library since other both the cli and tui apps could make use of it.
A separate cli application could be built by bugbite itself to query compatible configs known to it. That way if other frontends are developed, bite doesn't need to be installed to use more general bugbite-specific functionality.
In the same fashion as template support for create and modify.
When using the command line tool a significant amount of time is spent spinning up the server connection, usually between 90-95% of the total runtime. Having a way for the command line tool to reuse connections between separate executions could drastically speed up overall execution.
Bugzilla supports comment tags to mark comments as spam or obsolete and it would be nice to support modifying them via the command line.
Since bugbite-cli is moving to using asciidoc for its documentation, it would be useful to generate HTML from it to create online versions of the man pages and other documentation.
Bugzilla supports searching via changes made to field values, it would be handy if bugbite could support that as well.
Currently the implementation hard-codes a few fields to output depending on if they exist.
Currently bug modification support doesn't support flag mangling.
For various parameters that support ranges, it would be handy to support parsing rust-like ranges such as 1..10 and 1.. instead of implicitly converting to ranges. This should probably be implemented in the library since other both the cli and tui apps could make use of it.
It could be helpful to encode (and output) a humanized version of the query for simple debugging and feedback when running in verbose mode.
Basic issue modification should be supported as it is for bugzilla.
Users should be able to define their own connections and other related options in a config file loaded at runtime.
Currently only match-based value queries are supported.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.