Closed averissimo closed 1 year ago
BLUF: When searching for release dates for non-cran refs such as teal (>= 0.10.0)
it returns multiple dates (from GraphQL GH query) and a strategy to select for max date should be safe. Filtering for the actual tag doesn't seem possible/easy.
Action taken: Select for max date (it should be safe, as long as the version is specific v.#.#.#
with no further "sub-versions" as v0.10
with return all tags with this prefix v0.10.0-rc@pre-release
, v0.10.0
and v0.10.1
)
Context: GraphQL GH query returns the 2 tags v0.10.0
and v0.10.0-rc@pre-release
without any tag information.
note: Teal (>= 0.10.0) is just a public example that replicates a concrete use case.
The reproducible example below shows the problem. If we change the query for an empty string we can see that some tagged commits have Tag information and other don't (as far I know it's arbitrary with 6 out of 35 having the Tag metadata)
{
repository(owner: "insightsengineering", name: "teal") {
refs(refPrefix: "refs/tags/", query: "v0.10.0", first: 100) {
nodes {
target {
... on Commit {
committedDate
abbreviatedOid
}
... on Tag {
abbreviatedOid
commitResourcePath
commitUrl
message
name
oid
}
}
}
}
}
}
query: "v0.10.0"
)query: ""
-- empty)When searching for release dates for non-cran refs such as teal (>= 0.10.0) it returns multiple dates
Very interesting finding. Checked this on my own and I do confirm.
I looked into the code to see how you addressed it and it seems that you fixed it on the consumer side to handle returned vector of dates. Wouldn't be easier / better to assure that get_release_date
returns obj of length of one (in particular: NA
for not found or unknown remote-ref class) - that is: handle it on the producer side? As a general note, number of consumers tends to grow over time and each of them would have to have this "fix" which is not so DRY solution.
Wouldn't be easier / better to assure that
get_release_date
returns obj of length of one (in particular:NA
for not found or unknown remote-ref class) - that is: handle it on the producer side? As a general note, number of consumers tends to grow over time and each of them would have to have this "fix" which is not so DRY solution.
Very good point. I was doing this on the consumer side as it would make the get_ppm_snapshot_by_date()
robust to unexpected parameter lengths (as it just happened)
Better to enforce the select strategy on the producer! I'll make that change.
Is it too late to include checkmate
and start adding some parameter assertions to better prevent this?
Is it too late to include
checkmate
and start adding some parameter assertions to better prevent this?
I've been thinking about that and decided to go more modest way when it comes to deps at least for the beginning until we see a really strong reason to do so. This could be one of the reasons but I don't think it's so strong to enforce it. Let's wait and check if we find more cases where it will provide value.
ℹ️ base branch is
training
, notmain
See https://github.com/insightsengineering/nestdevs-tasks/issues/7 for overall progress
Notable changes:
resolve_ppm_snapshot()
out oflapply
local definition (re-used on Rcpp version enforcement){pkgdepends}
testthat@3.0.3
fails to compileget_release_date()
dun** (>= 0.1.3)
that retrieves tags0.1.3
and0.1.3-rc1
dun**
onchev**
package)resolve_ppm_snapshots
How to reproduce via docker container
(assumes a valid bash and docker/podman is installed)
Screenshots