Skip to content

Easier debugging ideas #146

Description

@hhorak

Brain dump of some ideas how to make the debugging easier:

  • print docker/podman version at the beginning of the test (plus some other related packages)
  • do some performance check at the beginning (how quickly network works by pulling some small image and installing a package; how quickly a container starts) -- seeing bigger numbers might indicate that the issues are caused by infra performance
  • add possibility to not dispose a machine immediately -- some message like [keep-alive: 2h] in the github comment could make the machine be kept a little longer after the test is done (see https://plugins.jenkins.io/ghprb/ for how to work with the comments)
  • similarly as the point above [debug] could turn on the debug (more verbose) output for the tests

Activity

  1. hhorak commented on Apr 24, 2020

    @hhorak
    MemberAuthor

    How the keep-alive could work: A simple solution would be to add sleep to the cleanup script:

    $ keep_time=$(echo "${ghprbCommentBody}" | grep -o '\[keep-machine[^]]*\]' | sed -e 's/\[keep-machine:\([^]]*\)\]/\1/')
    [ -n "${keep_time}" ] && echo "Keeping the machine $IP alive for ${keep_time}" && sleep "${keep_time}"
    

    Of course this can be enhanced by sending a github comment, tagging the person who added that comment etc...

  2. praiskup commented on Apr 24, 2020

    @praiskup
    Contributor

    Do you want to keep the VM allocated by resalloc alive, or the jenkins
    machine? If the former, new resalloc feature will be shipped in v3.0;
    you could put the machine into sandbox by --sandbox ... and anyone
    (perhaps person doing the debugging) could re-take the machine with
    the same --sandbox option (within pre-configured time-limit).

  3. praiskup commented on Apr 24, 2020

    @praiskup
    Contributor
  4. hhorak commented on Apr 24, 2020

    @hhorak
    MemberAuthor

    @praiskup wow, that helps, thanks. The original idea was very simple -- the job would wait and thus block the chain (there is a limit of 4 parallel jobs I think) -- so doing it through resalloc would be much better approach.

  5. phracek commented on Apr 24, 2020

    @phracek
    Member

    This would be really awesome. I am a volunteer for testing. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions