Travis-ci.com API获取仓库构建历史：after_number参数无效问题咨询

我来帮你搞定这个问题——你遇到的其实是Travis CI API的默认分页限制加上两个小细节没注意到，咱们一步步拆解：

为什么after_number参数好像没生效？ #

首先得明确：after_number确实在工作，但Travis CI v2 API默认每页最多返回50条构建记录，所以即使你指定了after_number，它也只会返回符合条件的前50条，而不是所有小于该编号的记录。这就是你只拿到50条的核心原因，不是参数失效，是分页限制在起作用。

另外，你命令里的User-Agen拼写错了，应该是User-Agent——虽然这个不一定直接导致参数失效，但规范的请求头能避免不必要的API异常，先修正这个小问题。

正确获取近30天所有构建的步骤 #

要拿到所有符合时间范围的记录，你需要循环分页请求，直到获取到30天前的记录为止，具体操作如下：

1. 初始请求：用你修正后的命令（注意User-Agent拼写）获取第一页的50条记录：

   curl https://api.travis-ci.com/repos/wixplosives/pleb/builds?after_number=293062563&sort_by=started_at:desc -H "Authorization: token MYTOKENGOESHERE" -H "User-Agent: Core3Client/1.0.0" -H "Accept: application/vnd.travis-ci.2.1+json" -H "Content-Type: application/json" -o travis-builds-page1.json
   

   这里加了sort_by=started_at:desc，确保结果按构建启动时间倒序排列，方便后续判断时间范围。

2. 提取下一页的after_number：打开返回的JSON文件，找到最后一条构建记录的number字段值（比如假设是293062000），这个值就是下一次请求的after_number参数。

3. 循环请求：重复执行curl命令，每次更新after_number为上一页最后一条的构建编号，直到返回的记录中出现启动时间早于30天前的条目，或者返回空数组为止。

4. 时间范围判断：提前计算30天前的ISO格式时间（比如2024-04-20T00:00:00Z），每次拿到新的构建记录后，检查每条的started_at字段，当遇到第一条时间早于这个值时，就可以停止后续请求了（后面的记录肯定都超出时间范围）。

小提示 #

如果你觉得手动分页太麻烦，可以写个简单的脚本（比如bash或Python）自动处理循环请求、拼接结果，这样能节省不少时间。比如用Python的话，可以用requests库循环发送请求，直到满足时间条件为止。

内容的提问来源于stack exchange，提问作者AlexS