Ask for extending default expiration date for initialized empty TiUP repo and supporting renewing after expiration
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 466
- Forks
- 338
- Avg merge
- 3d 7h
- Merged PRs (30d)
- 8
Description
Feature Request
Is your feature request related to a problem? Please describe:
I have built a TiUP repo from scratch using tiup mirror init and found that it would expire after one month, which is not an expected result for our project. Using tiup mirror merge <mirror> would update the expiration time but it would still be one month from the merging moment.

Another problem we encountered is that once the repo is expired, we would not have a chance to renew the expiration date through the command tiup mirror renew <component>.

Describe the feature you'd like:
Corresponding to the problems described above, I am wondering if the expiration date for the repo built by tiup mirror init could be longer, i.e., I have checked that the expiration date in the TiDB community server installation package(https://download.pingcap.org/tidb-community-server-v5.2.2-linux-amd64.tar.gz) is 2071-10-17T06:35:50Z.
Also, it would be better if we are able to recover an expired repo by tiup mirror renew.
Why the featue is needed:
The scenario would be like this:
- build an empty repo from scratch using
tiup mirror init - initialize the repo by publishing some project perspective components into it using
tiup mirror publish - put a TiDB community server installation package like tidb-community-server-v5.2.2-linux-amd64.tar.gz into the repo by
tiup mirror merge, which will be used to deploy v5.2.2 TiDB clusters. - once a new TiDB version is released, maybe some months later, we may want to merge the new package into the repo to deploy the new version TiDB clusters.
Clearly, we encountered the problem in step 4.
Describe alternatives you've considered:
I do not have alternatives for now.
Teachability, Documentation, Adoption, Migration Strategy:
N/A
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the tiup mirror init, tiup mirror merge, and tiup mirror renew command entry points and trace how repository expiration is set and validated. Done means an initialized repository can use a longer default expiration and an expired repository can be renewed; add or update coverage for both scenarios if the relevant tests are found.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100