Remove Eth fixturenet workflows #906

roysc · 2024-07-31T17:13:20Z

roysc commented

2024-07-31 17:13:20 +00:00

Deletes the now-failing CI workflows for the old fixturenet-eth and fixturenet-plugeth stacks.

Slack alerts for the updated stacks are set up in cerc-io/fixturenet-eth-stacks#20.

Part of #905.

Deletes the now-failing CI workflows for the old `fixturenet-eth` and `fixturenet-plugeth` stacks. Slack alerts for the updated stacks are set up in https://git.vdb.to/cerc-io/fixturenet-eth-stacks/pulls/20. Part of https://git.vdb.to/cerc-io/stack-orchestrator/issues/905.

roysc added 2 commits 2024-07-31 17:13:21 +00:00

Remove CI workflows for eth fixturenets 3c0d726c72

remove test scripts and trigger files

Lint Checks / Run linter (pull_request) Successful in 39s

Details

Deploy Test / Run deploy test suite (pull_request) Successful in 5m27s

Details

K8s Deploy Test / Run deploy test suite on kind/k8s (pull_request) Successful in 9m37s

Details

Webapp Test / Run webapp test suite (pull_request) Successful in 5m31s

Details

Smoke Test / Run basic test suite (pull_request) Successful in 4m10s

Details

752c9b30f0

roysc requested review from dboreham 2024-07-31 17:15:27 +00:00

roysc requested review from telackey 2024-07-31 17:15:27 +00:00

dboreham reviewed 2024-07-31 17:19:02 +00:00

dboreham left a comment

Looks like in the external repo we have some of these tests but lost the ARM test, and the manual triggers?

roysc requested review from prathamesh 2024-07-31 17:19:07 +00:00

roysc commented

2024-07-31 17:27:26 +00:00

The ARM test is configured with a value matrix now:

		.gitea/workflows/test-fixturenet-plugeth.yml
		Line 15 in 62c3ed67e3
	
				        os: [ubuntu-latest, ubuntu-latest-arm]

(in the Slack alerts PR, which should be merged before this)

I was thinking the manual triggers wouldn't be necessary in a dedicated repo, since most changes can propagate to all the stacks.

The ARM test is configured with a value matrix now: https://git.vdb.to/cerc-io/fixturenet-eth-stacks/src/commit/62c3ed67e38d25507eea1257c39fc60e74ef49b2/.gitea/workflows/test-fixturenet-plugeth.yml#L15 (in the Slack alerts PR, which should be merged before this) I was thinking the manual triggers wouldn't be necessary in a dedicated repo, since most changes can propagate to all the stacks.

dboreham commented

2024-07-31 17:30:41 +00:00

The ARM test is configured with a value matrix now:

.gitea/workflows/test-fixturenet-plugeth.yml Line 15 in 62c3ed67e3

os: [ubuntu-latest, ubuntu-latest-arm]

(in the Slack alerts PR, which should be merged before this)

I was thinking the manual triggers wouldn't be necessary in a dedicated repo, since most changes can propagate to all the stacks.

Ok nice on the matrix. I think we always need manual triggers on these jobs because changes made in other repos require re-test.
Almost every change that might break the test would be made in another repo.

> The ARM test is configured with a value matrix now: https://git.vdb.to/cerc-io/fixturenet-eth-stacks/src/commit/62c3ed67e38d25507eea1257c39fc60e74ef49b2/.gitea/workflows/test-fixturenet-plugeth.yml#L15 > (in the Slack alerts PR, which should be merged before this) > > I was thinking the manual triggers wouldn't be necessary in a dedicated repo, since most changes can propagate to all the stacks. Ok nice on the matrix. I think we always need manual triggers on these jobs because changes made in other repos require re-test. Almost every change that might break the test would be made in another repo.

roysc commented

2024-07-31 19:15:05 +00:00

Ok nice on the matrix. I think we always need manual triggers on these jobs because changes made in other repos require re-test.
Almost every change that might break the test would be made in another repo.

Okay partly makes sense. But those cases should be caught by the scheduled jobs, right?
And we can also re-run the latest run, although one job at a time. That seems simpler than needing to push to a branch to trigger a run.

> Ok nice on the matrix. I think we always need manual triggers on these jobs because changes made in other repos require re-test. > Almost every change that might break the test would be made in another repo. Okay partly makes sense. But those cases should be caught by the scheduled jobs, right? And we can also re-run the latest run, although one job at a time. That seems simpler than needing to push to a branch to trigger a run.

dboreham commented

2024-07-31 19:28:31 +00:00

I guess we disagree.

roysc commented

2024-07-31 19:59:20 +00:00

My main gripe with the trigger files is the need to opt-in to the job run by touching the file on every push.
But as it turns out this is only necessary in this repo because we don't have on.pull_request event triggers set, only push with the paths filter. We can just have both.

My main gripe with the trigger files is the need to opt-in to the job run by touching the file on every push. But as it turns out this is only necessary in this repo because we don't have `on.pull_request` event triggers set, only `push` with the `paths` filter. We can just have both.

dboreham commented

2024-07-31 20:02:39 +00:00

It depends. You can configure things either way. In some repos it makes sense to trigger on file changes.
In this one it made less sense to me because if you change a file related to the plugeth stack you don't want to trigger non-plugeth stack CI jobs which will floor the runners and hold you up. So manual trigger made more sense to me in this case.
But we can have either or both just a case of crafting the path filters in the job file.

It depends. You can configure things either way. In some repos it makes sense to trigger on file changes. In this one it made less sense to me because if you change a file related to the plugeth stack you don't want to trigger non-plugeth stack CI jobs which will floor the runners and hold you up. So manual trigger made more sense to me in this case. But we can have either or both just a case of crafting the path filters in the job file.

roysc commented

2024-07-31 20:18:55 +00:00

In this one it made less sense to me because if you change a file related to the plugeth stack you don't want to trigger non-plugeth stack CI jobs which will floor the runners and hold you up. So manual trigger made more sense to me in this case.

Right makes sense. That's why I figured we could skip it in the new repo (I was following Thomas' lead on this since he didn't add them). As more stacks are added (in the new repo) it could yet be desired.

> In this one it made less sense to me because if you change a file related to the plugeth stack you don't want to trigger non-plugeth stack CI jobs which will floor the runners and hold you up. So manual trigger made more sense to me in this case. Right makes sense. That's why I figured we could skip it in the new repo (I was following Thomas' lead on this since he didn't add them). As more stacks are added (in the new repo) it could yet be desired.

roysc changed title from ~~Remove CI workflows for Eth fixturenets~~ to Remove Eth fixturenet workflows

2024-07-31 20:28:57 +00:00

dboreham requested review from dboreham 2024-07-31 20:33:40 +00:00

dboreham approved these changes 2024-07-31 20:33:48 +00:00

roysc merged commit 0d4f4509c8 into main

2024-08-01 02:28:06 +00:00

roysc deleted branch roysc/rm-eth-workflows

2024-08-01 02:28:06 +00:00

roysc referenced this issue from a commit

2024-08-01 02:28:07 +00:00

Remove Eth fixturenet workflows (#906)

Sign in to join this conversation.

No reviewers

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/stack-orchestrator#906