You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should the MRAN repo be based on the current day that the build is being created, rather than being hardcoded? Or find the most recent MRAN archive to use? https://mran.revolutionanalytics.com/
It seems kind of unfortunate to have to update the URL whenever building or otherwise having packages potentially worth upgrading immediately after the build is created. E.g. right now the MRAN is 2.5 months old.
The text was updated successfully, but these errors were encountered:
It should be set to a particular day for reproducability. The day of the
build would work.
Ryan
On Thu, Jul 23, 2015 at 10:03 PM, Chris Kennedy [email protected]
wrote:
Should the MRAN repo be based on the current day that the build is being
created, rather than being hardcoded? Or find the most recent MRAN archive
to use? https://mran.revolutionanalytics.com/
It seems kind of unfortunate to have to update the URL whenever building
or otherwise having packages potentially worth upgrading immediately after
the build is created. E.g. right now the MRAN is 2.5 months old.
—
Reply to this email directly or view it on GitHub #57.
Right, for the "most recent MRAN" option it would still be hardcoded in the actual AMI, but it would handle the contingency that there may not be an MRAN folder for the day of the build for whatever random reason.
Should the MRAN repo be based on the current day that the build is being created, rather than being hardcoded? Or find the most recent MRAN archive to use? https://mran.revolutionanalytics.com/
It seems kind of unfortunate to have to update the URL whenever building or otherwise having packages potentially worth upgrading immediately after the build is created. E.g. right now the MRAN is 2.5 months old.
The text was updated successfully, but these errors were encountered: