Page MenuHomeFreeBSD

Allow developers to run their own Workflows(Github) and CI(Cirrus)
AbandonedPublic

Authored by bofh on May 9 2022, 10:21 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 23 2023, 10:00 AM
Unknown Object (File)
Nov 8 2023, 6:49 AM
Unknown Object (File)
Nov 6 2023, 10:30 AM
Unknown Object (File)
Nov 3 2023, 6:45 AM
Unknown Object (File)
Oct 7 2023, 5:43 AM
Unknown Object (File)
Oct 5 2023, 10:13 AM
Unknown Object (File)
Oct 4 2023, 9:27 AM
Unknown Object (File)
Oct 1 2023, 6:47 AM

Details

Reviewers
emaste
imp
Summary

This patch handles couple of issues mentioned here:

  1. If someone forks our src tree; and do have Github Actions enabled it runs these by default. Update Github Workflow to run the test only if the repository owner is freebsd. If developers want to run the same they can do it by just copying and removing one line. But I believe developers have other tests required beyond this smoke test.
  2. Same for Cirrus-CI. In addition to 1. the name of the task is renamed to smoke_task so that others can add their tests with a proper naming convention.
  3. Github do not only read worflows from BASE_DIR/.github/workflows but wherever they find any .gihub/workflows in any sub directory inside the BASE_DIR. We have couple of folders which have .github/workflows which I am proposing to delete. Mainly:
    1. crypto/openssh/.github/workflows which is not harmful and can coexist
    2. contrib/libarchive/.github/workflows which has no effect in our environment and tries to run the workflows
    3. contrib/libcbor/.github/workflows which has no effect in our environment and tries to run the workflows
    4. sys/contrib/openzfs/.github/workflows which has no effect in our environment and tries to run the workflows. These also creates tons of artifacts which goes beyond the free limits of Github Workflows. And we do have our zfs test job in Jenkins.

Most of these specially 3 are not visible unless you have a private fork for whatever the reason is. So in case we do not want to delete we can at least safe-guard these with specific owner or repo name.

Test Plan

This do no have any effects on our Github repo.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

bofh requested review of this revision.May 9 2022, 10:21 PM
bofh edited the summary of this revision. (Show Details)

There are developers who want to run these tasks on their own forks - at least, I do. Users could also configure Cirrus-CI not to run on their fork, if so desired (i.e., by not giving Cirrus-CI access to the specific repo).

Is there a way to provide arbitrary per-user metadata that we could key on instead?

There are developers who want to run these tasks on their own forks - at least, I do. Users could also configure Cirrus-CI not to run on their fork, if so desired (i.e., by not giving Cirrus-CI access to the specific repo).

I think these are very basic tests compared to our thorough test plans. I am not talking about the groups who do not want to run Cirrus-CI at all. They are outside the scope of this.

Is there a way to provide arbitrary per-user metadata that we could key on instead?

I am not sure if I can understand you properly on this but so far I cannot see that option. But we can work on another thing that is GIT branch. In Github it's much more easier as we can split Workflows into multiple files. But in Cirrus what we can do is we can split into two same tasks preconfigured. In one case that is the current situation when the URL freebsd/freebsd-src and the branch is main. And on another case where the repo owner is not freebsd and the branch is not main. Cause eventually noone(I doubt though) commits on main branches on fork.

Some sort of similar behavior has been put into action with $CIRRUS_REPO_FULL_NAME != 'freebsd/freebsd-src'