Split `test-infra` repo into `tools` and `infra` repos about test-infra HOT 9 CLOSED

Thanks for the write up and issue! I like the idea of us cloning /test-infra to /tools and /infra and archiving test-infra for history sake.

from test-infra.

I'd rather not move GitHub actions away from our knative/actions repository - that's the central spot for reusable actions

from test-infra.

The idea is once infra is cleaned up and should only be hosting prow, terraform, etc we would think about bringing in actions there where we would still use reusables, but that would be probably later once we move more to actions and spin down our dependence on prow. Is there any big push back reason you would have for keeping actions separate at that point?

from test-infra.

@dprotaso If we move those actions, it would be just a minor change for consuming repos.

jobs:
  test:
-     uses: knative/actions/.github/workflows/go-test.yaml@main
+     uses: knative/infra/github/workflows/go-test.yaml@main

I think that's doable. Looks easy.

from test-infra.

Is there any big push back reason you would have for keeping actions separate at that point?

I just don't see the value of the churn - and you'll have to keep the old actions around for at least 6 months so you don't break release branches (or you update branches as well)

from test-infra.

If we decide to move the actions (for sure, that's for the future, not now), we'll definitely leave the old repo in place as a read-only archive.

Also, the old branches, should really be using actions from a specific release, not the tip. We know otherwise repos CI may be in a defunct state and will require manual revitalization, by aligning actions to previous, compatible versions.

from test-infra.

Also, the old branches, should really be using actions from a specific release, not the tip. We know otherwise repos CI may be in a defunct state and will require manual revitalization, by aligning actions to previous, compatible versions.

A big con to this approach is you could be building with older golang versions that could have a CVE

from test-infra.

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

from test-infra.

basically done

from test-infra.