Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 920
    • Issues 920
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 21
    • Merge requests 21
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #17636
Closed
Open
Created Apr 17, 2020 by Cyril 'kibi' Brulebois@CyrilBrulebois

tails-iuk: test suite usefulness/expectations

Originally created by @CyrilBrulebois on #17636 (Redmine)

We’ve had a little chat lately about the tails-iuk test suite, I’m quoting parts of the discussion between intrigeri and me (as usual, I’m asking questions, intrigeri has answers):

>> The way I see it, running this test suite is primarily useful:
>>  - When a developer works on the code base, to iterate quickly before
>>    pushing to CI (I do mostly TDD on our Perl code bases; this
>>    requires a short feedback loop).
>>
>>    Given I work on sid, CI would help me spot regressions
>>    that happen in a Tails-like environment, but not on my system.
>>
>>    And for other people, what you're saying is very true: for example,
>>    if *you* can't reliably run the test suite, you cannot work on this
>>    code base with confidence. That's a problem.
>>
>>  - When a reviewer looks at a submitted branch.
>>  - When a RM wants to build confidence in the state of the code
>>    they're going to publish.
>>
>>    I think server-side CI, run in a Tails-like environment, would be
>>    sufficient. That's what we're doing for other dev work, where we
>>    don't expect reviewers and RMs to *also* run the CI locally.
>>    Fair enough?
>
> In this specific case, what would a Tails-like environment mean? A
> Buster+ system?

Ideally it would be run inside a running Tails system, possibly as
part of our test suite. And if that's cheaper, IMO it's good enough to
set the bar at the same level as Debian sbuild/autopkgtest, i.e. "a
clean system running the same Debian release as current Tails, with
the needed dependencies installed".

I'd rather not run that server-side CI in an environment that runs
a newer Debian than Tails: I've already seen cases when the code that
worked on my sid would break in Debian stable.

> Maybe with a hint somewhere based on /etc/os-release or lsb_release
> warning developers/RMs when they run it on an older system? In this
> case, if ID=debian and VERSION_ID is << 10?

Sounds good to me!

Related issues

  • Related to sysadmin#6218 (moved)
Edited May 15, 2020 by Cyril 'kibi' Brulebois
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking