expire_in无法使用

非常抱歉给你带来了困惑。在 GitLab CI/CD 中，确实没有直接支持 `expire_in` 参数来设置缓存的存在时间。

我之前提到的 `expire_in` 是一个错误的信息，感谢你的指正。

在 GitLab CI/CD 中，缓存的存在时间是由系统自动管理的，根据缓存策略和访问情况来确定。默认情况下，GitLab CI/CD 会根据缓存的最后访问时间进行清理，以保持合适的存储空间。

如果你需要更加精确地控制缓存的存在时间，你可以考虑使用其他方法，如在构建脚本中手动清理过期的缓存或使用自定义的过期检查逻辑。

再次对之前的错误回答表示歉意，希望这次能给你提供正确的信息。如果还有其他问题，请继续提问。

相关问题

cache config contains unknown keys: expire_in

抱歉，我的回答有误。在 GitLab CI/CD 中，`.gitlab-ci.yml` 文件中的 `cache` 部分不支持直接设置缓存的存在时间。缓存的过期时间是根据缓存策略和配置来确定的。

默认情况下，GitLab CI/CD 缓存的存在时间是根据缓存的最后访问时间来计算的。如果缓存在一段时间内没有被访问，则会被清除。

如果你希望手动控制缓存的存在时间，可以使用自定义的方式，例如在缓存内容中添加时间戳或版本号，并在构建脚本中检查缓存的时效性，然后手动清除过期的缓存。

另外，GitLab 也提供了一些高级缓存配置选项，例如使用 `cache:key` 来区分不同的缓存策略和版本，并使用 `cache:policy` 来设置缓存的访问策略。你可以根据自己的需求配置这些选项来管理缓存。

总而言之，GitLab CI/CD 的缓存存在时间是根据默认策略和访问情况来确定的。如果需要更精确地控制缓存的存在时间，可以考虑自定义实现或使用高级缓存配置选项。

NOT (T.BUSINESS_ID = ANY(500000020064, 500000020340) AND T.OFFER_TYPE IN ('OFFER_PLAN_BROADBAND', 'OFFER_PLAN_WBTV') AND T.EXPIRE_DATE < TO_DATE('20990101', 'YYYYMMDD')

根据您提供的条件语句，这是一个包含多个条件的逻辑表达式。它使用了 NOT 运算符和多个条件组合。

根据您提供的条件语句，我们可以将其拆解如下：

NOT (
    T.BUSINESS_ID = ANY(500000020064, 500000020340)
    AND T.OFFER_TYPE IN ('OFFER_PLAN_BROADBAND', 'OFFER_PLAN_WBTV')
    AND T.EXPIRE_DATE < TO_DATE('20990101', 'YYYYMMDD')
)

这个表达式的含义是：如果以下所有条件都不满足，则返回 true，否则返回 false。

- `T.BUSINESS_ID = ANY(500000020064, 500000020340)`: T 表的 BUSINESS_ID 列的值等于 500000020064 或 500000020340。
- `T.OFFER_TYPE IN ('OFFER_PLAN_BROADBAND', 'OFFER_PLAN_WBTV')`: T 表的 OFFER_TYPE 列的值在 'OFFER_PLAN_BROADBAND' 或 'OFFER_PLAN_WBTV' 中。
- `T.EXPIRE_DATE < TO_DATE('20990101', 'YYYYMMDD')`: T 表的 EXPIRE_DATE 列的值小于 '20990101'。

如果上述条件中的所有条件都不满足，则整个逻辑表达式返回 true。否则，返回 false。

请注意，这只是一个逻辑表达式的解释，具体如何使用这个表达式可能取决于您所使用的数据库和上下文。