Closed acmiyaguchi closed 9 years ago
I suspect that the server will actually reject requests with this field specified -- please test before we land this!
I don't think there's a good reason to put a limit on the TTL for a file. If someone finds a reason to want to upload a file with, say, a 18-month TTL for an ESR-like thing, why should they have to patch the client to allow that?
I'll make sure to add in those annotations, I'll bump this again when I'm done implementing the server side stuff, that might be a better time to land.
Looks like I'll have to do some merge resolutions :\
This is looking good, though
@acmiyaguchi I've lost track .. this is ready for more review? merge?
Review would be appropriate given the time lapse. This should be merged in after the appropriate PR has been merged into build-relengapi.
Holding off on this until the relengapi changes are deployed
This was backed out from relengapi based on some objections brought up in the bug. I'm going to close this PR since it's not in motion right now. The code is still here, and I also captured it at https://github.com/mozilla/build-tooltool/tree/bug1167636 just in case @acmiyaguchi wants to use his master
branch for something else.
This adds a --ttl option in the tooltool client, which will optionally add a ttl field to the manifest that is an integer in days. Valid values for the time to live are between 1 to 365 days, inclusive. I figure having the file expire any longer than that isn't all that useful, this would normally be used for smaller values (say one or two days). The field will default to a value of None, which will keep the file permanent.
This option will need to be implemented in the tooltool server, and should otherwise be ignored.
Link to referenced bug 1167636