Update actions

[seabbs]

Description

This PR closes #.

Initial submission checklist

• My PR is based on a package issue and I have explicitly linked it.
• I have tested my changes locally (using devtools::test() and devtools::check()).
• I have added or updated unit tests where necessary.
• I have updated the documentation if required and rebuilt docs if yes (using devtools::document()).
• I have followed the established coding standards (and checked using lintr::lint_package()).
• I have added a news item linked to this PR.

After the initial Pull Request

• I have reviewed Checks for this PR and addressed any issues as far as I am able.

[seabbs]

I'm seeing simulate_secondary and simulate_infections failing here. I can't see how this can be related to this PR?

[sbfnk]

I'm seeing simulate_secondary and simulate_infections failing here. I can't see how this can be related to this PR?

Me neither. How very odd.

[seabbs]

Testing a dummy PR in #773

[seabbs]

One potential factor here is could this have a newer version of cmdstan or cmdstanr? If yes perhaps the recent change in the random number generator explains this?

[sbfnk]

One potential factor here is could this have a newer version of cmdstan or cmdstanr? If yes perhaps the recent change in the random number generator explains this?

But the changes here shouldn't change the cmdstan(r) version and the tests pass on main.

[seabbs]

maybe they do because

1. I am using the epinowcast action which auto-detects the latest cmdstan version vs fixing it (which is the thing that is hard to make work all the time)
2. It is pulling from the non-depreciated cmdstanr source and maybe that gives a different version.

If its not that and if #773 works I can't imagine what it can be

[sbfnk]

But the windows action fails which doesn't use cmdstan?

[seabbs]

oh.... Any chance its getting rstan from the additional repo vs from CRAN and hence having version mismatch issues?

[seabbs]

#773 does pass so it is definitely something in this PR

[seabbs]

The stan universe hosts the dev version of rstan which is 3 stan minor versions ahead of the CRAN version. That includes the random number gen change I believe so I think it has to be this.

[seabbs]

So we have a few options.. I am not sure how to control which package is installed from which repo via additional repositories. If we can do that then maybe that is the solution?

[sbfnk]

This is very confusing. Ubuntu installs rstan 2.32.6 whereas the dev version was installed in #775

[jamesmbaazam]

Removing myself as reviewer since Seb is reviewing.

[seabbs]

Removing myself as reviewer since Seb is reviewing.

Sorry this was an intentional ping @jamesmbaazam as seb has now committed code

[sbfnk]

@seabbs just flagging the failure of the epinowcast cmdstan action in the merged PR which presumably will happen here too https://github.com/epiforecasts/EpiNow2/actions/runs/10956025463/job/30421154764

[seabbs]

its the cmdstan version lookup code. Really unclear why that is stochastically unstable. There must be a better way of getting the latest release

[seabbs]

maybe using the gh package

[seabbs]

if we set a version vs trying to find the latest one then that will go away

[sbfnk]

its the cmdstan version lookup code. Really unclear why that is stochastically unstable.

Presumably because we're not sending an auth token along?

[sbfnk]

maybe using the gh package

or just using the existing functionality for identifying / downloading the latest release in cmdstanr?

[seabbs]

or just using the existing functionality for identifying / downloading the latest release in cmdstanr?

Does it have this before it starts installing? We need it earlier to set the cache name

[seabbs]

Presumably because we're not sending an auth token along?

I'm not using the API at all at the moment. It sends its a call to curl: https://github.com/epinowcast/actions/blob/d7ff9df01f7b37f1cd366a6e8dc499c9accd13d0/install-cmdstan/scripts/get-latest-release.sh#L22

[sbfnk]

Presumably because we're not sending an auth token along?

I'm not using the API at all at the moment. It sends its a call to curl: https://github.com/epinowcast/actions/blob/d7ff9df01f7b37f1cd366a6e8dc499c9accd13d0/install-cmdstan/scripts/get-latest-release.sh#L22

Isn't that the problem then given it yields a 403, i.e. the server receives the request but refuses to process?

[sbfnk]

or just using the existing functionality for identifying / downloading the latest release in cmdstanr?

Does it have this before it starts installing? We need it earlier to set the cache name

I guess yes if you're willing to use non-exported functions such as e.g. cmdstanr:::latest_released_version() https://github.com/stan-dev/cmdstanr/blob/f2e152b88fde5c2cde01ff078d5715b3b6248628/R/install.R#L401 - but of course that might introduce different pain points. Alternative would be to use -H in curl to send the github auth token in the header.

[seabbs]

Alternative would be to use -H in curl to send the github auth token in the header.

That is a good idea

[sbfnk]

Finally managed to get this to work by deleting the install-cmdstan cache.

[sbfnk]

@jamesmbaazam just needs your approval then should be good to merge