lima
lima copied to clipboard
lima-vm
Increase timeout for resolving IP Address.
Will you follow this option?
How about adding a GitHub Actions workflow to sign off commits automatically if not done? This will help ensure compliance with the Developer Certificate of Origin (DCO) and streamline the contribution process.
Here is an example workflow that can be added to the repository:
name: Auto Sign-Off
on:
pull_request:
types: [opened, synchronize]
jobs:
signoff:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Git
run: |
git config --global user.name "github-actions[bot]"
git config --global user.email "github-actions[bot]@users.noreply.github.com"
- name: Sign off commits
run: |
for commit in $(git rev-list --reverse HEAD ^origin/main); do
git cherry-pick $commit --strategy=recursive -X theirs --signoff
done
- name: Push changes
run: |
git push origin HEAD:refs/heads/${{ github.head_ref }} --force
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
How about adding a GitHub Actions workflow to sign off commits automatically if not done? This will help ensure compliance with the Developer Certificate of Origin (DCO) and streamline the contribution process.
Nope, rather opposite, as automated signs are unlikely valid
it is kind of a hack though, I won't merge it unless it gets another approval
It was already hack with 2 minutes, I don't see how 3 minutes make it worse...
- https://github.com/lima-vm/lima/pull/1625
The real hack is making GitHub Actions into a special case, is what I'm thinking
Why was the test failed with
msg="did not receive an event with the \"running\" status"?
We can re-run the test to see if it is just a flake, but you also need to squash your commits together and sign it with a DCO before it can be considered for merging (assuming there will otherwise be consensus that the change is desirable).
Why was the test failed with
msg="did not receive an event with the \"running\" status"?
Due to this timeout. https://github.com/lima-vm/lima/blob/463ed828cb5fa0a2851a54f15941f85c189d8b82/pkg/start/start.go#L36
@jandubois Are there any objections to changing this in this PR?
Due to this timeout. https://github.com/lima-vm/lima/blob/463ed828cb5fa0a2851a54f15941f85c189d8b82/pkg/start/start.go#L36
@jandubois Are there any objections to changing this in this PR?
I would like to first see some evidence that a longer timeout "fixes" the issue.
I have a suspicion that something is just wedged, and it will never get ready until it is killed and restarted. In that case increasing the timeout will just mean it takes even longer before CI eventually fails.
So maybe use a much longer timeout in a branch, and re-run the tests a bunch of times, to see if they will then always pass.
Only then can we meaningfully discuss if we want to extend the timeout, and if it should again be gates by running inside GitHub actions.
it will never get ready until it is killed and restarted.
first two attempts failed with msg="[hostagent] QEMU did not exit in 3m0s, forcibly killing QEMU"
third one with msg="error starting docker: cannot restart, VM not previously started" (inference => 1st essential requirement is satisfied in ~7mins (3+3+1))
here I didn't kill, stop, or delete it.
Same behavior even after stopped.
Use the CUSTOM_TIMEOUT environment variable to configure the timeout for resolving IP addresses.
- Import the
strconvpackage. - Add a new variable
customTimeoutto read theCUSTOM_TIMEOUTenvironment variable. - Parse the
CUSTOM_TIMEOUTvalue and set thetimeoutvariable accordingly.
For more details, open the Copilot Workspace session.
@lima-vm/reviewers Where are we with this PR? I think we can merge it now, but I think the environment variable should be documented "somewhere", I just can't figure out where. Any suggestions?
https://lima-vm.io/docs/usage/#customization Here?
I think that page is supposed to be simple and have just the high-level examples.
Maybe we need an extra page under the "Configuration Guide"?
Maybe we need an extra page under the "Configuration Guide"?
With the name "Environment Variables", documenting $LIMA_INSTANCE too?
Maybe we need an extra page under the "Configuration Guide"?
With the name "Environment Variables", documenting $LIMA_INSTANCE too?
Sounds good to me.
In that case include all the other variables too (LIMA_SHELL, LIMA_WORKDIR, LIMACTL), and document where/when they are used.
LIMA_INSTANCE and LIMACTL are supported by lima and lima.bat, but LIMA_SHELL and LIMA_WORKDIR only by lima. LIMA_INSTANCE is also supported by docker.lima and kubectl.lima... Please check all the places!
Copilot Workspace for updating docs
It touches 8 files. First 2 is enough?
Should I update the docs in this PR itself?
Should I update the docs in this PR itself?
No, separate PR is fine since it will document more than just the single variable in this PR.
Please squash the commits
Isn't squash and merge not enabled for this repo?
Isn't squash and merge not enabled for this repo?
No, it is up to the PR author to combine commits and write a commit message that covers the squashed commits correctly.
Also (but rarely) there is justification for squashing commits into just a smaller number of commits instead of a single one. This should only be done to separate different areas of functionality, and not to maintain the individual steps that lead to the final change.
Typically this means that the 2 separate commits should have been 2 separate PRs.