Migrating to travis-ci.com
shivaburade opened this issue · comments
Bug Report
What happened:
The travis-ci.org site will not run any new builds after June 15th, 2021.
Do we have any plans to migrate the repository to travis-ci.com? This is important for architectures like s390x which have CI support through Travis only.
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
- Kubernetes version (use
kubectl version
): - service-catalog version:
- Cloud provider or hardware configuration:
- Do you have api aggregation enabled?
- Do you see the configmap in kube-system?
- Does it have all the necessary fields?
kubectl get cm -n kube-system extension-apiserver-authentication -o yaml
and look forrequestheader-XXX
fields
- Install tools:
- Did you use helm? What were the helm arguments? Did you
--set
any extra values?
- Did you use helm? What were the helm arguments? Did you
- Are you trying to use ALPHA features? Did you enable them?
Thank you for bringing attention to the travis-ci.org. We do intend to move the builds in the near future. I'll keep this issue open until the migration is complete.
Thank you for your response. Is there any updates on this?
Other projects have been struggling with the new travis infrastructure, as well as their pricing model. We'll have to explore other options for running our tests on all supported platforms.
@jhvhs Could you please elaborate more on the issues/struggles faced by the projects due to the new Travis infrastructure?
As per the Travis blog, Travis fully supports the OSS teams and allocates them more credits after they apply for the same.
Could you please open a request with Travis CI support stating that you'd like to be considered for the OSS allotment?
Please refer to the Travis blog for more details on how to open a support request with Travis.
@jhvhs any updates?
@jhvhs any updates?
@jhvhs any updates?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale
- Mark this issue or PR as rotten with
/lifecycle rotten
- Close this issue or PR with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
@jhvhs any updates?
This project is being archived, closing open issues and PRs.
Please see this PR for more information: kubernetes/community#6632