use gh to ask the API of GitHub and et a list of issues
with their labels and milestones.
get_issues(selector, verbose = TRUE, ...)
get_labels(selector, verbose = TRUE, ...)
get_milestones(selector, verbose = TRUE, ...)A SelectorTB object (to define the range of the repo /
source used). Created with init_selector().
A boolean indicating whether to print additional
information. Default is TRUE.
Other parameters for GitLab as gitlab_url and private_token.
The function get_issues returns an object of class IssuesTB. It
is a list composed by object of class IssueTB. An object of class
IssueTB represents an issue with simpler structure (with number,
title, body and labels).
The function get_labels returns a list representing labels with
simpler structure (with name, description, colour).
The function get_milestones returns a list representing milestones
with simpler structure (with title, description and due_on).
The functions of get type are useful to retrieve object related to issues from GitHub. So it's possible to retrieve issues, labels and milestones.
The defaults value for the argument dataset_name depends on the
function:
defaults is "list_issues.yaml" for get_issues()
defaults is "list_milestones.yaml" for get_milestones()
defaults is "list_labels.yaml" for get_labels()
# \donttest{
# From online
online_selector <- init_selector(
source = "GitHub",
owner = "TanguyBarthelemy",
repo = "IssueTrackeR"
)
issues <- get_issues(selector = online_selector)
#> Repo: IssueTrackeR owner: TanguyBarthelemy
print(issues)
#> There are 25 issues.
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#69 ──
#>
#> Title: `init_selector` should accept a `dataset_name` and `dataset_dir` arg instead of
#> Text:
#> To match with the writing step, `init_selector` should accept a `dataset_name` and `dataset_dir `arg instead of `file`.
#> So `update_database` should be able to accept a init_selector with `source = "local"`.
#>
#> - [ ] Replace `file` by `dataset_name` and `dataset_dir` in `init_selector`
#> - [ ] In `get_XXX_local`, match the
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#68 ──
#>
#> Title: New vignette on selectors
#> Text:
#> - Qu'est ce qu'un selector ?
#> - Quels types de source il peut contenir ?
#> - Comment est ce qu'il se créé ?
#> - Comment est ce qu'il s'affiche ?
#> - Comment ajouter un nouveau selector à une liste de selectors ?
#> - Comment retirer un selector d'une liste de selectors ?
#> - Comment extraire un selector d'une liste ?
#> - Comment s'a
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#66 ──
#>
#> Title: Bug: no class with no selector
#> Text:
#> ``` r
#> library("IssueTrackeR")
#> #> Currently, the default options are:
#> #> - location for datasets: /tmp/Rtmp5CLf0Q/data
#> #> - name for the datasets: fqkvb
#> #> - selector:
#> #>
#> #> Attaching package: 'IssueTrackeR'
#> #> The following objects are masked from 'package:base':
#> #>
#> #> append, sample, write
#> class(get_labels(init_
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#65 ──
#>
#> Title: [goodpractice] roxygen2_has_export_or_nord
#> Text:
#> ```
#> ✖ Tag every documented function with either `@export`, `@noRd`, or `@rdname`. Functions
#> without roxygen2 documentation are implicitly internal and do not need tagging.
#>
#> R/check.R:254
#> R/format.R:26
#> R/get.R:154
#> R/get.R:232
#> R/get.R:281
#> ... and 27 more lines
#> ```
#>
#> *All the issues starting with
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#64 ──
#>
#> Title: [goodpractice] roxygen2_valid_inherit
#> Text:
#> ```
#> ✖ Ensure functions referenced by `@inheritParams` and `@inheritDotParams` exist within the
#> package. Use `pkg::func` syntax for external functions.
#>
#> R/format.R:137
#> R/update_database.R:35
#> R/wrangling_issues.R:49
#> R/wrangling_repo.R:20
#> R/write.R:159
#> ```
#>
#> *All the issues starting with [goodpractice
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#63 ──
#>
#> Title: [goodpractice] roxygen2_duplicate_params
#> Text:
#> ```
#> ✖ use `@inheritParams` to avoid duplicating parameter documentation. Identical `@param`
#> descriptions across files suggest shared docs should be inherited from a single source.
#>
#> R/finding-objects.R:34
#> R/finding-objects.R:93
#> R/finding-objects.R:133
#> R/plot.R:56
#> R/plot.R:122
#> ... and 46 more li
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#62 ──
#>
#> Title: [goodpractice] tidyverse_object_usage_linter
#> Text:
#> ```
#> ✖ avoid defining variables that are never used and ensure all referenced objects are defined
#> or imported.
#>
#> R/finding-objects.R:339:19
#> R/format.R:241:15
#> R/format.R:264:17
#> R/format.R:278:17
#> R/format.R:290:21
#> ... and 64 more lines
#> ```
#>
#> *All the issues starting with [goodpractice] are results
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#61 ──
#>
#> Title: [goodpractice] tidyverse_r_file_names
#> Text:
#> ```
#> ✖ name R files using `-` or `_` to delimit words and use a .R extension, e.g.
#> prefix-my_function.R. Avoid capital letters and spaces.
#>
#> ./R/IssueTrackeR-package.R
#> ```
#>
#> *All the issues starting with [goodpractice] are results from the [{goodpractice}](https://github.com/ropensci-review-tools/goodpractice) packa
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#60 ──
#>
#> Title: [goodpractice] tidyverse_test_file_names
#> Text:
#> ```
#> ✖ name test files to mirror the R source file they test, e.g. R/my_function.R should have
#> tests/testthat/test-my_function.R.
#>
#> R/comments.R
#> R/contributor.R
#> R/finding-objects.R
#> R/format.R
#> R/IssueTrackeR-package.R
#> ... and 4 more lines
#> ```
#>
#> *All the issues starting with [goodpractice] are resu
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#59 ──
#>
#> Title: [goodpractice] tidyverse_no_missing
#> Text:
#> ```
#> ✖ avoid using `missing()` to check whether arguments were supplied. The tidyverse style guide
#> recommends using `NULL` defaults with `is.null()` instead, as `missing()` makes functions
#> difficult to call programmatically.
#>
#> R/wrangling_issues.R:308
#> R/wrangling_issues.R:442
#> ```
#>
#> *All the issues starting wit
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#58 ──
#>
#> Title: [goodpractice] tidyverse_export_order
#> Text:
#> ```
#> ✖ define exported (user-facing) functions before internal helper functions within each R
#> source file.
#>
#> R/contributor.R:4
#> R/get.R:154
#> R/get.R:232
#> R/get.R:281
#> R/get.R:372
#> ... and 23 more lines
#> ```
#>
#> *All the issues starting with [goodpractice] are results from the [{goodpractice}](https://git
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#57 ──
#>
#> Title: [goodpractice] covr
#> Text:
#> ```
#> ✖ write unit tests for all functions, and all package code in general. 62% of code lines are covered by
#> test cases.
#>
#> R/check.R:222
#> R/check.R:223
#> R/check.R:224
#> R/check.R:225
#> R/check.R:226
#> ... and 737 more lines
#> ```
#>
#> *All the issues starting with [goodpractice] are results from the [{goodpra
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#56 ──
#>
#> Title: [goodpractice] complexity_unused_internal
#> Text:
#> ```
#> ✖ remove or use internal functions that are defined but never called. Dead code increases maintenance
#> burden.
#>
#> R/contributor.R:4
#> R/wrangling_issues.R:442
#> R/wrangling_issues.R:467
#> R/wrangling_issues.R:476
#> ```
#>
#> *All the issues starting with [goodpractice] are results from the [{goodpractice}](https:
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#55 ──
#>
#> Title: [goodpractice] complexity_function_length
#> Text:
#> ```
#> ✖ keep functions short and focused. Long functions are harder to understand, test, and maintain. Consider
#> splitting into smaller helpers. (Default limit of 50 set with option
#> 'goodpractice.function_length_limit').
#>
#> R/check.R:254
#> R/format.R:195
#> R/format.R:341
#> R/get.R:281
#> R/get.R:600
#> ... a
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#53 ──
#>
#> Title: Coverage v2.1.0
#> Text:
#> To continue the coverage, we put a goal of **90%** for v2.1.0.
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#52 ──
#>
#> Title: Mutators test coverage for v2.1.0
#> Text:
#> I am setting a coverage target of **30%** for version 2.1.0, using mutators.
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#50 ──
#>
#> Title: no default for repo and owner and dir
#> Text:
#> BY default, we should set dir to `NULL` or to `""`. So when getting the issues (`get_issues`) we can switch source to "online" if dir is not defined.
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#49 ──
#>
#> Title: Extract labels and milestones from issues
#> Text:
#> The functions `get_labels` and `get_milestones` should work with `IssueTB` and `IssuesTB` objects.
#>
#> The goal is to extract all the labels and milestones used in a list of issues or in an issue.
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#47 ──
#>
#> Title: Bonnes pratiques de documentation
#> Text:
#> Suivre les bonnes pratiques de documentation :
#>
#> - [ ] Boolean et non Logical
#> - [ ] Suivre le guide écrit pour le rjdverse
#> - [ ] Mettre `` `my_fun` `` plutôt que `\code{my_fun}` et uniformiser les usages
#>
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#44 ──
#>
#> Title: Complete `goodpractice::goodpractice()` checkup
#> Text:
#> Here is the output from {goodpractice}:
#>
#> ```
#> > gp
#> ── It is good practice to ───────────────────────────────────────────────────────────────────────
#>
#> ✖ keep functions short and focused. Long functions are harder to understand, test, and maintain.
#> Consider splitting into smaller helpers. (Default limit of 50 set with o
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#43 ──
#>
#> Title: What to do with type?
#> Text:
#> Une question que je me pose : Si j'ouvre une issue (mais task, bug ou autre) et que je la ferme avec différent attribut (won't do, duplicated...) qu'est ce qu'il va s'afficher dans l'appel gh::gh ?
#> Aussi est ce que je peux récupérer cette nouvelle info (type) et l'ajouter ? -> que se passe t-il pour les anciennes issu
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#24 ──
#>
#> Title: Continue coverage
#> Text:
#> The current coverage is 26%. We should update it a lot!
#>
#> Some functions are not tested:
#>
#> - [x] `[.IssuesTB`
#> - [ ] `[[<-.IssuesTB`
#> - [ ] `[<-.IssuesTB`
#> - [ ] `add_n_years`
#> - [ ] `append`
#> - [ ] `append.default`
#> - [ ] `append.IssuesTB`
#> - [ ] `author_last_comment`
#> - [ ] `author_last_comment.IssuesTB`
#> - [ ] `author_last_com
#> ...
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#22 ──
#>
#> Title: Change yaml to parquet
#> Text:
#> Is it possible to add this *new feature*?
#>
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#20 ──
#>
#> Title: [New feature] Who contributes?
#> Text:
#> Créer un nouveau graphiques / nouvelle statistiques sur la contribution des personnes (ouvrir des issues, répondre, les fermer, mettre des commentaires...)
#>
#> ── Issue TanguyBarthelemy/IssueTrackeR#16 ──
#>
#> Title: [Bug] `update_database()` needs a new argument for `list_issues.yaml`
#> Text:
#> Hi there, thank you so much for the fantastic package.
#>
#> When I download the issues as `get_issues(source = "online", state = "all")` and then write the database to local, I get a `list_issues.yaml` output. However, the `update_database()` function does not have a `list_issues` argument to read this issue table that co
#> ...
#>
labels <- get_labels(selector = online_selector)
#> Repo: IssueTrackeR owner: TanguyBarthelemy
#> Reading labels... Done!
#> 41 labels found.
print(labels)
#> There is 1 repo.
#> - TanguyBarthelemy/IssueTrackeR:, automated issue, communication, complexity: complex, complexity: moderate, complexity: trivial/easy, complexity: very-complex, documentation, duplicate, effort: long, effort: medium, effort: short, effort: unknown, effort: very-long, good first issue, good practice, help wanted, invalid, missing examples, priority: critical, priority: high, priority: low, priority: medium, question, report, status: can't-reproduce, status: completed, status: duplicate, status: in-progress, status: needs-information, status: on-hold, status: review-needed, status: triage, status: won't-do/fix, tests, type: bug, type: enhancement, type: feature, type: maintenance, type: question, typo, wontfix
milestones <- get_milestones(selector = online_selector)
#> Repo: IssueTrackeR owner: TanguyBarthelemy
#> Reading milestones...
#> - v2.1.0 ... Done!
#> - v2.0.0 ... Done!
#> Done! 2 milestones found.
print(milestones)
#> source title description due_on closed_at creator state
#> 1 GitHub v2.1.0 <NA> <NA> TanguyBarthelemy open
#> 2 GitHub v2.0.0 2026-10-31 <NA> TanguyBarthelemy open
#> nb_issues_open nb_issues_closed repo owner
#> 1 6 0 IssueTrackeR TanguyBarthelemy
#> 2 17 9 IssueTrackeR TanguyBarthelemy
#> url
#> 1 https://github.com/TanguyBarthelemy/IssueTrackeR/milestone/7
#> 2 https://github.com/TanguyBarthelemy/IssueTrackeR/milestone/2
# }
# From local
local_issues_selector <- init_selector(
source = "Local",
file = file.path(
system.file("data_issues", package = "IssueTrackeR"),
"list_issues.yaml"
)
)
local_labels_selector <- init_selector(
source = "Local",
file = file.path(
system.file("data_issues", package = "IssueTrackeR"),
"list_labels.yaml"
)
)
local_milestones_selector <- init_selector(
source = "Local",
file = file.path(
system.file("data_issues", package = "IssueTrackeR"),
"list_milestones.yaml"
)
)
issues <- get_issues(selector = local_issues_selector)
#> The issues will be read from /home/runner/work/_temp/Library/IssueTrackeR/data_issues/list_issues.yaml.
labels <- get_labels(selector = local_labels_selector)
#> The labels will be read from /home/runner/work/_temp/Library/IssueTrackeR/data_issues/list_labels.yaml.
milestones <- get_milestones(selector = local_milestones_selector)
#> The milestones will be read from /home/runner/work/_temp/Library/IssueTrackeR/data_issues/list_milestones.yaml.