[WIP] Commit for test ci, ignore this pr

[horizonzy]

Commit for test ci, needn't view.

[github-actions]

@horizonzy:Thanks for your contribution. For this PR, do we need to update docs?
(The PR template contains info about doc, which helps others know more about the changes. Can you provide doc-related info in this and future PR descriptions? Thanks)

[nicoloboschi]

could you explain more why you split the test?
it doesn't show up correctly in the CI results? can you provide an example?

[horizonzy]

could you explain more why you split the test? it doesn't show up correctly in the CI results? can you provide an example?

Not mint it, I'm trying to find the flaky test root case, split it just for find.

[nicoloboschi]

@horizonzy ok, I suggest you to set the pull as draft, add "WIP" in the title or create it in your fork to not cause confustion

[horizonzy]

@horizonzy ok, I suggest you to set the pull as draft, add "WIP" in the title or create it in your fork to not cause confustion

I try it at my fork and upstream both... It will be faster for test.

[lhotari]

@horizonzy If you want to test the CI or modify it, please consider opening PRs to your own fork of apache/pulsar since we have very limited resources in apache/pulsar.
In your own fork, you can run GitHub Actions workflows independently and your builds won't cause the build queue to grow in apache/pulsar.

[horizonzy]

@horizonzy If you want to test the CI or modify it, please consider opening PRs to your own fork of apache/pulsar since we have very limited resources in apache/pulsar. In your own fork, you can run GitHub Actions workflows independently and your builds won't cause the build queue to grow in apache/pulsar.

fine, after ci done at this time, I won't do it again.

[lhotari]

fine, after ci done at this time, I won't do it again.

@horizonzy +1. There are some instructions in https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0 about using "Personal CI".

[lhotari]

@horizonzy The additional benefit of the "Personal CI" is that you get ssh access to the build VMs when the build is running. That is handled by this logic in the pulsar-ci.yaml GitHub Actions workflow file:

pulsar/.github/workflows/pulsar-ci.yaml

Lines 77 to 82 in 1682884

	- name: Setup ssh access to build runner VM
	# ssh access is enabled for builds in own forks
	if: ${{ github.repository != 'apache/pulsar' && needs.changed_files_job.outputs.docs_only != 'true' }}
	uses: ./.github/actions/ssh-access
	with:
	limit-access-to-actor: true

and inline composite action implementation: https://github.com/apache/pulsar/blob/master/.github/actions/ssh-access/action.yml

The ssh acccess is secured with the ssh key registered in Github. for example, your public keys are https://github.com/horizonzy.keys . You will first have to register a ssh public key in GitHub for that to work.

[horizonzy]

@horizonzy The additional benefit of the "Personal CI" is that you get ssh access to the build VMs when the build is running. That is handled by this logic in the pulsar-ci.yaml GitHub Actions workflow file:

Thanks your guide