< Return to Video

salsa.debian.org state of affairs

  • Not Synced
    Ok, welcome back to the second session
    of the day.
  • Not Synced
    It's going to be Alexander Wirt talking
    about salsa.debian.org.
  • Not Synced
    [Applause]
  • Not Synced
    Thank you, good morning.
  • Not Synced
    I usually don't give talks in english,
    so please be nice to me.
  • Not Synced
    However, I'm here.
  • Not Synced
    I want to talk today about our journey
    for Alioth
  • Not Synced
    which is still running, but not for long
    anymore,
  • Not Synced
    to our new service, salsa.
  • Not Synced
    I want to get a little bit into the history
    of old things
  • Not Synced
    and what we have already achieved,
    what we still need to achieve
  • Not Synced
    and what are our plans for the future.
  • Not Synced
    Let's start with the basic things,
    who am I.
  • Not Synced
    I am the guy who rejects the mails
    on lists.debian.org,
  • Not Synced
    I am a listmaster.
  • Not Synced
    I am the guy that rejects your backports.
  • Not Synced
    I am the backports ftp master.
  • Not Synced
    And I am the guy that will destroy
    alioth.debian.org.
  • Not Synced
    For the last ten years
  • Not Synced
    [Applause]
  • Not Synced
    I was an admin by accident of
    alioth.debian.org.
  • Not Synced
    This is another story I will tell you
    in a few minutes.
  • Not Synced
    Beside from that, I work as an OpenSource
    consultant at credativ,
  • Not Synced
    which is a small company in Germany
    which is specialized in OpenSource,
  • Not Synced
    we only do OpenSource consulting
    in Germany.
  • Not Synced
    We do what today is called DevOps,
    we do every kind of consulting.
  • Not Synced
    If you do something with OpenSource,
    we are probably the ones you can talk with.
  • Not Synced
    I am a father of two wonderful girls,
  • Not Synced
    they're not here unfortunately,
  • Not Synced
    but otherwise I wouldn't be able
    to work.
  • Not Synced
    And in my little bit spare time, I do
    role playing games and Tabletop games.
  • Not Synced
    In theory there should be a picture now.
  • Not Synced
    There's a picture missing,
    I don't know why,
  • Not Synced
    which should tell "We need you".
  • Not Synced
    A little bit of advertisement, if you
    want to do OpenSource work in Germany,
  • Not Synced
    paid,
  • Not Synced
    and you need a job, please talk to me.
  • Not Synced
    We are always looking for good people,
    especially in C development,
  • Not Synced
    kernel development, but also of course
    consulting.
  • Not Synced
    So please talk to me.
  • Not Synced
    Some steps in history.
  • Not Synced
    Some years ago, ???
    2008, 2009,
  • Not Synced
    I told the alioth channel
  • Not Synced
    "Hey, if you need help, I can help with
    system administration,
  • Not Synced
    not the GForge stuff which is running
    above,
  • Not Synced
    but if you need help, tell me."
  • Not Synced
    [Audience] Big mistake
  • Not Synced
    Yeah.
  • Not Synced
    One or two years went by,
    and step by step
  • Not Synced
    all alioth admins left.
  • Not Synced
    We were alone in the channel.
  • Not Synced
    And around that time, I detected
  • Not Synced
    "Hey, I have sudo permissions
    and I'm admin"
  • Not Synced
    Somebody made me an admin.
  • Not Synced
    So, I had to decide that I will be
    the person that is the future alioth admin
  • Not Synced
    and I stepped in.
  • Not Synced
    So it was the beginning of our alioth
    journey.
  • Not Synced
    Then, in DebConf15, we had a long
    'Birds of a Feather'
  • Not Synced
    where we talked about several security
    problems in collab-maint,
  • Not Synced
    some of you are maybe not aware of it,
  • Not Synced
    but since we use git at filesystem level
    on alioth,
  • Not Synced
    we are introducing a number of interesting
    security problems
  • Not Synced
    like if someone writes a hook, that hook
    gets executed every time someone pushes.
  • Not Synced
    So you have basically shell access.
  • Not Synced
    And of course you execute it as
    your own uid.
  • Not Synced
    So, if some DM (Debian Maintainer) or even
    not DM, nearly the whole world
  • Not Synced
    has write access to collab-maint,
  • Not Synced
    drops some hooks in,
  • Not Synced
    it can make you execute code on Alioth
    at your uid, which is a problem.
  • Not Synced
    We did some things to solve that problem,
    but the main problem remained.
  • Not Synced
    So, along that time, we decided that we
    would need a successor for git.debian.org.
  • Not Synced
    At that point, we are talking about gitolite
  • Not Synced
    which we evaluated at that time.
  • Not Synced
    However, as ???
  • Not Synced
    Two years went into the land and
    nothing real happened,
  • Not Synced
    we just played with it.
  • Not Synced
    Then, May 2017, a thread comes up,
    "Moving away from fusionforge".
  • Not Synced
    What nobody was really aware of, is that
    alioth is on a Wheezy machine
  • Not Synced
    and Wheezy is ??? out of security
    support end of the month.
  • Not Synced
    So time was running up.
  • Not Synced
    The thread was long as usual on
    debian-devel and
  • Not Synced
    we decided to do a few steps, like
    evaluating things
  • Not Synced
    and in June 2017, I did a survey about
    our new alioth services.
  • Not Synced
    It was clear at that point that I wouldn't
    be able to maintain all the things
  • Not Synced
    alioth had in the future
  • Not Synced
    so we decided to just bring over
    the important things.
  • Not Synced
    What is important? For everyone,
    everything else is important
  • Not Synced
    so I decided to do a survey which was
    pretty successful
  • Not Synced
    with a few hundreds submissions.
  • Not Synced
    Then, in…
  • Not Synced
    Then we evaluated… "we" as probably "me",
  • Not Synced
    evaluated a few solutions, named pagure,
    which is the git solution Fedora is using,
  • Not Synced
    which is a Python thing based on gitolite,
  • Not Synced
    gitlab, which is the biggest Github
    competitor
  • Not Synced
    gogs/gitea, which is some golang-based
    small git service.
  • Not Synced
    pagure turned out to be not stable enough
    for our needs
  • Not Synced
    and we would have to do to much coding
    inside pagure to use it in our infrastructure
  • Not Synced
    because pagure is very strongly ???
    with the Fedora infrastructure,
  • Not Synced
    specially its user authentication and
    user management stuff.
  • Not Synced
    Gitlab had an other problem called
    "opencore" and
  • Not Synced
    "contributor license agreement"
    which means
  • Not Synced
    I and others were not very happy with
    contributing code to Gitlab
  • Not Synced
    which is something that will always
    happen if you maintain such a service.
  • Not Synced
    And gogs and gitea is nice but it's small
  • Not Synced
    It will not be able to manage 10,000s
    of repositories.
  • Not Synced
    Next step happened in August 2017 when
    we had a sprint here in Hamburg
  • Not Synced
    at the hackerlab CCC on the other side
    of the building,
  • Not Synced
    where we talked about it.
  • Not Synced
    After long discussions, we decided to go
    with Gitlab
  • Not Synced
    because Gitlab, at that point, was
    the best solution that was already ready.
  • Not Synced
    We didn't have to adapt too much, we don't
    need to patch it
  • Not Synced
    which turned out it isn't true, but it's
    an other problem
  • Not Synced
    It had features like continuous integration
    ready,
  • Not Synced
    it had features like code review ready,
    wiki pretty good working
  • Not Synced
    and ??? very scalable
    in all directions
  • Not Synced
    Every component is scalable which is
    good for us.
  • Not Synced
    This is a TODO point, I wanted to add
    an image about the restaurant
  • Not Synced
    where we decided on the name "salsa".
  • Not Synced
    Somebody of you may ask yourself where
    the name is coming from.
  • Not Synced
    There's a small mexican restaurant
    a few hundred meters from here
  • Not Synced
    where you can get great burritos and
    they have a painting at the back
  • Not Synced
    with the term "salsa" written
  • Not Synced
    and we were deciding on a name which
    just not describes the type of service on it
  • Not Synced
    so we wanted…
  • Not Synced
    Yes, it's also a sauce. So salsa had sauce.
  • Not Synced
    I wanted to call it Klaus, but we decided
    against it so somebody came up
  • Not Synced
    in the restaurant with the name "salsa"
    and so it's called salsa.
  • Not Synced
    In the meanwhile, we talked a lot with
    the Gitlab people
  • Not Synced
    which were very kind and helped us
    with our problems.
  • Not Synced
    We also talked with them about the CLA
    problem and after some discussions,
  • Not Synced
    the lawyer of SPI was also involved,
  • Not Synced
    we made them to remove the CLA
    and replace it with something better.
  • Not Synced
    Contributing patches to Gitlab is now
    much easier and better
  • Not Synced
    which is something we are very proud of
  • Not Synced
    [Applause]
  • Not Synced
    And between November and the 25th of
    December, we implemented salsa two times
  • Not Synced
    First time on ???.debian.net where we had
    root but
  • Not Synced
    after more discussions we decided having
    this maintained at a (debian).org box
  • Not Synced
    would be better, which made us
    ??? ansible stuff
  • Not Synced
    and develop a ??? to be able to install
    gitlab as a non-privileged user
  • Not Synced
    but we did that.
  • Not Synced
    In Christmas, he was able to release
    salsa into public beta.
  • Not Synced
    Things went well, which allowed, at the
    end of January, salsa to leave the beta
  • Not Synced
    Since then it's official, our official
    git successor.
  • Not Synced
    What will happen in the future?
  • Not Synced
    Oh no, this is already past.
  • Not Synced
    On May, we disable user and project
    creation on alioth.
  • Not Synced
    Still in May, we disabled the not so much
    used version control systems,
  • Not Synced
    bazaar, mercurial and darcs
  • Not Synced
    On Thursday (May 17th 2018), I disabled
    projects web sites.
  • Not Synced
    And this is future, at the end the month,
  • Not Synced
    all other remaining version control systems
    on alioth will get disabled.
  • Not Synced
    So if you have anything running on alioth,
    still running on alioth,
  • Not Synced
    cron jobs are also disabled so
    you don't have cron jobs enabled anymore
  • Not Synced
    Be it whatever you think of, remove it.
  • Not Synced
    1st of June, alioth will be off, you won't
    be able to get any data anymore
  • Not Synced
    from alioth.
  • Not Synced
    You can get the ??? via DSA to get
    subsequent backups, that's up to you
  • Not Synced
    but I don't recommend it and they won't
    like it.
  • Not Synced
    Yeah
  • Not Synced
    In June, alioth will come to an end.
  • Not Synced
    It served us well for 10, 15 years, but
    its time is over.
  • Not Synced
    Some numbers.
    Where are we now?
  • Not Synced
    Yesterday (May 18th 2018), we had
    23,700 repositories on gitlab,
  • Not Synced
    3200 users, 400 groups, which sums up
    around 90GB on disk, which is nice.
  • Not Synced
    For a service running for more or less
    6 months, it's a pretty nice number.
  • Not Synced
    What are our future plans.
  • Not Synced
    ??? Docker registry, by now
    you can use external registries
  • Not Synced
    which is working
  • Not Synced
    You can the gitlab registry for
    Docker images
  • Not Synced
    but it will be nicer to have our own
    registry.
  • Not Synced
    That is pretty high on my todo list, after
    alioth is gone.
  • Not Synced
    We want more runners, so you are able to
    sponsor runners, if you have machines or
  • Not Synced
    some money you want to spend on runners,
    please tell us.
  • Not Synced
    What are runners? Runners are the things
    that are used by Gitlab CI to build code
  • Not Synced
    or test code, or do things.
  • Not Synced
    You can use it to build your packages,
    you can use it to autopkgtest you packages
  • Not Synced
    you can use it to build websites or
    whatever you like.
  • Not Synced
    It's pretty useful and I think using CI more
    will be a big step forward for Debian.
  • Not Synced
    We should really get more into it.
  • Not Synced
    There are already some projects like
    the reproducible builds, the debci guys
  • Not Synced
    that are working on such stuff
  • Not Synced
    and now we have the infrastructure that
    every DD, every developer or package maintainer
  • Not Synced
    can use it.
  • Not Synced
    There's also an other feature called
  • Not Synced
    "devops" which is based on kubernetes
    which allows you to even
  • Not Synced
    deploy and test things properly.
  • Not Synced
    So if you have package which implements
    a web service, you can even run
  • Not Synced
    ??? kubernetes part which runs
    a web server,
  • Not Synced
    you can test it, you can even record it,
    do QA test and so on
  • Not Synced
    all based on this devops feature which
    would also be a nice thing.
  • Not Synced
    By now, we don't have a kubernetes instance
    we can use for it,
  • Not Synced
    so if you have a spare kubernetes instance
    you want to offer Debian,
  • Not Synced
    please talk to us.
  • Not Synced
    And integration with sso.debian.org,
    which is another side project of mine
  • Not Synced
    and some of ??? students, sitting there.
  • Not Synced
    We want to build a successor for
    the command sso.debian.org
  • Not Synced
    which has a problem that it doesn't have
    a user backend,
  • Not Synced
    the user backend is alioth,
    you see the problem
  • Not Synced
    But it just the case for our guest users.
  • Not Synced
    The official Debian Developers come from
    the ldap which will still work,
  • Not Synced
    but we have a problem with guest users,
    so we currently don't have a way to
  • Not Synced
    source for managing those guest users,
    especially give additional groups like
  • Not Synced
    "Hey, the user's a DM"
  • Not Synced
    I would love to give all DMs access to
    the Debian group, write access,
  • Not Synced
    but I can't currently because I'm not able
    to ???
  • Not Synced
    which is something we want to solve with
    the new sso.debian.org feature.
  • Not Synced
    sso.debian.org should also develop a new
    authentication protocol like OAuth2,
  • Not Synced
    which we will use for salsa but new
    services can also rely on,
  • Not Synced
    ??? a way from this certificate stuff
    which is somewhat nice
  • Not Synced
    but it's not that good integrated in most
    browsers anymore
  • Not Synced
    and it doesn't work that well.
  • Not Synced
    We hope to have, we already have
    a prototype, and we hope to have it live
  • Not Synced
    until the end of the summer.
  • Not Synced
    What we left behind.
  • Not Synced
    We don't have shells anymore.
  • Not Synced
    So you won't be able to run any cron jobs
    or other stuff on salsa and
  • Not Synced
    please don't ask, we won't give anyone
    a shell on salsa.debian.org or godard
  • Not Synced
    which is the host hosting it.
  • Not Synced
    We hape APIs, several of them,
    I will show them
  • Not Synced
    Please use them, we won't run any
    cron jobs or custom stuff on gitlab,
  • Not Synced
    it was a nightmare on alioth to maintain
    and to administrate
  • Not Synced
    and I will never, never want to get
    into this again.
  • Not Synced
    What we also don't have are custom domains
    which is a feature gitlab has, but
  • Not Synced
    DSA decided against it, so you will have
    to live with
  • Not Synced
    projectname.pages.debian.net until
    someone decides for that feature.
  • Not Synced
    We also left behind old version…
    not so much anymore version control systems
  • Not Synced
    like darcs, bazaar, subversion which isn't
    a problem,
  • Not Synced
    but we also don't have cvs anymore,
    which may be a surprise for someone
  • Not Synced
    but Debian is still a heavy user of cvs,
    especially for our web site
  • Not Synced
    and translations.
  • Not Synced
    But maybe they will now migrate faster
    away from cvs.
  • Not Synced
    They are working on it, I know,
    they're working on it for 10 years
  • Not Synced
    but things are getting faster and
    they're making progress
  • Not Synced
    in migrating away from cvs.
  • Not Synced
    Yeah, ???, that's right,
    we also left mercurial,
  • Not Synced
    or whatever people have in their
    home directory.
  • Not Synced
    Yeah we also had rcs on alioth, there
    were rcs repos, yes.
  • Not Synced
    What we got instead.
  • Not Synced
    We got a bunch of new features
    we didn't have before.
  • Not Synced
    So, this is such… maybe a start of new
    ways of working in Debian,
  • Not Synced
    we got a bunch of collaboration features.
  • Not Synced
    In the past, collaboration often meant
    finding the right mailing list,
  • Not Synced
    sending a patch and hoping.
  • Not Synced
    Now we can use merge requests, which
    allow people to easily fork and
  • Not Synced
    modify packages or repositories, and after
    they are done, they can just hit a button
  • Not Synced
    or whatever and create a nice merge
    request which is already heavily used
  • Not Synced
    by some projects like apt or dak or my own
    redirector.
  • Not Synced
    That allows ???, the admins
    of those repositories/projects
  • Not Synced
    to review code easily, they can add
    comments, they can discuss with
  • Not Synced
    ??? people out of the mailing list.
  • Not Synced
    If people update a bunch and they
    commited, those merge requests
  • Not Synced
    get updated which is a workflow we are
    also using very heavily in our company
  • Not Synced
    which is pretty nice in my eyes.
  • Not Synced
    This also allows contribution to packages
    from outside people
  • Not Synced
    It lowers the barrier for people to
    collaborate with Debian,
  • Not Synced
    which is in my eyes a good feature,
  • Not Synced
    something I always liked on Github and
    I'm happy we are having it too now.
  • Not Synced
    Gitlab has a nice feature of good, well
    designed web frontend,
  • Not Synced
    some things could be better, but it's
    always the case,
  • Not Synced
    but in most cases Gitlab is still
    blazingly fast
  • Not Synced
    except if you've hit some of the bugs
    in the API
  • Not Synced
    but that's an other problem.
  • Not Synced
    And you can work with it.
  • Not Synced
    If you don't like the web frontend,
    use the API,
  • Not Synced
    nearly everything the web frontend
    supports is exposed via the API
  • Not Synced
    And there are also a bunch of
    command line clients
  • Not Synced
    which can integrate into git to allow
    things like merge requests,
  • Not Synced
    allow you to process merge requests
    from the command line
  • Not Synced
    if you don't like web frontends.
  • Not Synced
    You can also open merge requests
    by e-mail if you still like it
  • Not Synced
    you can just hit the right buttons,
    you'll get a mail address
  • Not Synced
    that you can use.
  • Not Synced
    And if you send a patch to that mail address
    you will create a merge request,
  • Not Synced
    some of the not so known research.
  • Not Synced
    Issues.
  • Not Synced
    You can track todo items or bugs.
  • Not Synced
    Please, this is not intended for Debian
    packages,
  • Not Synced
    so please don't replace the BTS
  • Not Synced
    but using it as an issue tracker or todo
    lists is great.
  • Not Synced
    We are using it all the time.
  • Not Synced
    We're also having some upstream projects
    on salsa, like sane or ???
  • Not Synced
    which is ???
  • Not Synced
    So, they're using issues, that's fine too.
  • Not Synced
    Issues are disabled by default for
    a project,
  • Not Synced
    but every project has ??? to just
    enable it and to use it.
  • Not Synced
    You have boards where you can organize
    your work,
  • Not Synced
    you can add sprints, you can add
    milestones and other things,
  • Not Synced
    all the basic stuff you need to have
    an issue tracker is included.
  • Not Synced
    And we also enabled reply by mail so
    you don't have to use the web frontend,
  • Not Synced
    you can just use your mail client
    to reply ??? into gitlab.
  • Not Synced
    You can also close issues by merge requests.
  • Not Synced
    So, similar to our BTS, Gitlab has
    this "closes" feature.
  • Not Synced
    It's all the same. So "Close", "Closes"…
    and so on, it's all the same
  • Not Synced
    and we close here your issues.
  • Not Synced
    You can even close issues in other
    projects,
  • Not Synced
    so if you have projects related together
    and you fix something in another project
  • Not Synced
    you can even close it with that syntax.
  • Not Synced
    You can also create issues by mail,
    which is basically the same
  • Not Synced
    as for merge requests,
  • Not Synced
    you have that "email new issue" button
    where you get a custom mail address you can use
  • Not Synced
    and then you can use that mail address
    for the future
  • Not Synced
    to submit bugs if you don't want to use
    the issue tracker.
  • Not Synced
    What we also got are webhooks.
  • Not Synced
    Custom hooks are not anymore possible
    because you don't have access to
  • Not Synced
    the repositories directly
  • Not Synced
    but what you can use are webhooks.
  • Not Synced
    Webhooks are common standard in the
    web world,
  • Not Synced
    you can use them to react to events
    in your repository,
  • Not Synced
    events may be things like someone created
    an issue, someone created a pull request,
  • Not Synced
    someone pushed something, someone took
    something, things like that.
  • Not Synced
    And you can use those events to create
    IRC notifications,
  • Not Synced
    we have two IRC bots available for you
    to use, which is KGB
  • Not Synced
    and my own irker instance.
  • Not Synced
    You can automatically close or tag
    bugs
  • Not Synced
    If you look into our documentation,
    wiki.debian.org,
  • Not Synced
    you find a small paragraph about it
    where you can just,
  • Not Synced
    as we did before, if you close a bug
    and you enable the tag pending,
  • Not Synced
    tag pending webhook, your bug will
    be tagged automatically as pending
  • Not Synced
    like before if you used the ???
    hooks on alioth.
  • Not Synced
    And you can also trigger external CI QA
    systems, like Jenkins or SonarQube
  • Not Synced
    or whatever you like to test you code.
  • Not Synced
    In the future, we will also use it
    for collab, for the collaboration stuff
  • Not Synced
    from tincho, where we will just forward
    every push happened on the whole salsa system
  • Not Synced
    so you don't have to configure that
    manually, it will happen automatically
  • Not Synced
    So if you contribute something to Debian,
    it will come up on collab.debian.net
  • Not Synced
    If you want to provide webhooks but you
    don't want to run your own web server,
  • Not Synced
    you can come to us, which means you have
    to code Ruby.
  • Not Synced
    We have our own webhook server implementation
    for salsa.debian.org,
  • Not Synced
    which is currently also running on salsa,
    but that must be the case in the future.
  • Not Synced
    So, if you want to run a webhook, provide us
    a patch for our webhook implementation
  • Not Synced
    which is pluggable, so write a plugin which
    listens to your webhooks,
  • Not Synced
    provide a patch, a merge request and we'll
    happily add it to our webhook implementation
  • Not Synced
    so it can be used for everybody.
  • Not Synced
    Documentation is in the wiki.
  • Not Synced
    Currently provided hooks are, as already
    mentioned, tagpending
  • Not Synced
    which allows you to tag bug as pending if
    you mention them in you changelog
  • Not Synced
    and some project directly working with
    commits are using the close webhook
  • Not Synced
    which allows you to directly close
    a bug with a commit
  • Not Synced
    which is used by some web servers and
    other stuff directly used in Debian.
  • Not Synced
    One of the most powerful features we got
    is Gitlab CI.
  • Not Synced
    Gitlab CI is a system that allows
    a continuous integration,
  • Not Synced
    continuous development on salsa
  • Not Synced
    and that allows you to build, test and
    eventually deploy software and packages
  • Not Synced
    from within Gitlab.
  • Not Synced
    You can nearly do whatever you want
    in this CI stuff,
  • Not Synced
    you can compile ???, run linter,
    run autopkgtest,
  • Not Synced
    whatever you can imagine you can do.
  • Not Synced
    We have two runners provided.
  • Not Synced
    One of it is running as an ???
    on Google cloud,
  • Not Synced
    the other one is hardware sponsored
    by a sponsor
  • Not Synced
    and for every CI run, we launch a docker
    container in it,
  • Not Synced
    You can even provide an image you want
    to use as this one
  • Not Synced
    and then you can do whatever you want
    with it.
  • Not Synced
    But please don't do bitmining or
    something like that,
  • Not Synced
    be kind to them, we all have to use them
    and we have only two of them,
  • Not Synced
    so please, if you want to do something
    bigger, talk to us
  • Not Synced
    like the KDE people already did.
  • Not Synced
    How to use it?
  • Not Synced
    Using Gitlab CI is surprisingly easy.
  • Not Synced
    There is this gitlab-ci.yml file which is
    usually in the root of your repository
  • Not Synced
    but you can add configuration to your
    repository, for example to
  • Not Synced
    add it to your /debian repository
    which works better for
  • Not Synced
    ??? packages
  • Not Synced
    or whatever you have, if you don't want to
    clutter the upstream directories
  • Not Synced
    of your gitlab-ci file.
  • Not Synced
    [Question about potential conflicts with
    gitlab-ci files from upstream]
  • Not Synced
    We already have a bug opened on the
    Gitlab issue tracker
  • Not Synced
    that allows us to change the default name
    of the gitlab-ci file because
  • Not Synced
    currently, if you import an external
    repository, which has a gitlab-ci file
  • Not Synced
    which can happen,
  • Not Synced
    if we ??? run on our infrastructure
    and for example,
  • Not Synced
    it's ansible or some other project
    ???
  • Not Synced
    for every upstream commit, salsa will
    ??? run our runners
  • Not Synced
    and build the pipeline.
  • Not Synced
    After you edit your file, that's it.
  • Not Synced
    From then on, you can watch every commit
    happening on your pipeline.
  • Not Synced
    This is a simple gitlab-ci file, gitlab-ci
    files are yaml-based,
  • Not Synced
    documentation is in the Gitlab repository,
    the documentation repository and
  • Not Synced
    as you can see, it's pretty easy, you have
    a pre-step, which allows you to do things
  • Not Synced
    like installing dependencies which is
    what's happening here.
  • Not Synced
    Since Gitlab CI is running a detached
    head, if you want to ???
  • Not Synced
    use git buildpackage, we will have to
    checkout master
  • Not Synced
    for it to properly work,
  • Not Synced
    then you can do a git pull, git buildpackage
    and, after that,
  • Not Synced
    you have build your package.
  • Not Synced
    That's basically all.
  • Not Synced
    You can also use artifacts.
  • Not Synced
    Artifacts allow you to… keep a build
    artifact for downloading, so
  • Not Synced
    if you want someone to use a package,
    you can just add an artifact stanza here
  • Not Synced
    and that allows you to later download
    your deb files.
  • Not Synced
    Now that doesn't allow you to create
    a repository ???
  • Not Synced
    but it's an other problem.
  • Not Synced
    If it's too much, you can also use the
    ??? yesterday
  • Not Synced
    This is a prepared docker container which
    is prepared for git buildpackage and
  • Not Synced
    all you have to do is to execute this.
  • Not Synced
    After that, you have Gitlab CI.
  • Not Synced
    [Applause]
  • Not Synced
    I don't know who provided it, but it popped
    up in the wiki yesterday
  • Not Synced
    or something like that.
  • Not Synced
    We also have Gitlab pages.
  • Not Synced
    Gitlab pages are like Github pages and
    allow you to host web sites,
  • Not Synced
    static web sites from within Gitlab.
  • Not Synced
    Internally they also use Gitlab CI, so
    you provide a Gitlab CI job
  • Not Synced
    that just deploys your website, so
    it's nothing to do
  • Not Synced
    and here's our build artifact feature.
  • Not Synced
    All we do here is just add those public
    files in the public directory to our pages
  • Not Synced
    and we only do this on the master branch
  • Not Synced
    and basically that's it.
  • Not Synced
    The magic is happening here, it's the
    "pages" step and
  • Not Synced
    if you correctly configure pages in your
    repository configuration,
  • Not Synced
    you have a Gitlab page after that.
  • Not Synced
    You can also do more fancy things like
    a Hugo web site,
  • Not Synced
    just depend on a docker image which has
    hugo installed
  • Not Synced
    and then execute a script which builds
    Hugo, add some artifacts
  • Not Synced
    and after that you have a Hugo website.
  • Not Synced
    You can also use it for blogs, you can
    use it in personal repositories,
  • Not Synced
    then for example for your own web site
    or blogs.
  • Not Synced
    Of course, it's not intended to serve
    big web sites
  • Not Synced
    but providing blogs for planet.debian.org
    is perfectly fine, for example
  • Not Synced
    or web site of ??? project or
    whatever is Debian-related.
  • Not Synced
    This brings me to an other topic
    not mentioned in my slides
  • Not Synced
    some people asked us what is fine to host
    on salsa.
  • Not Synced
    As long as it's open source, as long as
    it's intended to be Debian-related
  • Not Synced
    or open source related or can be included
    in Debian,
  • Not Synced
    it's perfectly fine to host it on salsa.
  • Not Synced
    So we invite every upstream which is
    looking for a home,
  • Not Synced
    like the SANE guys, to host them
    on salsa.
  • Not Synced
    What we got with the latest major version
    is a web editor
  • Not Synced
    which is pretty new,
  • Not Synced
    probably buggy, but it works.
  • Not Synced
    So, if you don't want to clone
    a repository
  • Not Synced
    or you have just to have simple changes,
    you can add your file in the web editor,
  • Not Synced
    you get a web editor with syntax
    highlighting,
  • Not Synced
    you get even a markdown preview if you
    just do documentation,
  • Not Synced
    so that's great for every one just doing
    documentation
  • Not Synced
    that doesn't want to ??? with git
  • Not Synced
    or the code inside, you can even
    preview it,
  • Not Synced
    then you can write a commit message,
  • Not Synced
    and that's it.
  • Not Synced
    What we also have is two-factor
    authentication, which is a security feature
  • Not Synced
    that allows you to add a second factor
    to your Gitlab login.
  • Not Synced
    I can only recommend to use it, that's
    well integrated and adds a lot of security.
  • Not Synced
    It works with Yubikeys or any U2F-compatible
    key
  • Not Synced
    and also with software solutions that
    implement TOTP,
  • Not Synced
    time-based one time passwords.
  • Not Synced
    So every TOTP-compatible generator also
    works, for example the Google authenticator
  • Not Synced
    but there are also others which are
    open source, that all works.
  • Not Synced
    Adding it is easy.
  • Not Synced
    ???
  • Not Synced
    It's easy.
  • Not Synced
    What you can't see now is me getting
    my smartphone out,
  • Not Synced
    scanning the bar code, generating a PIN
    code,
  • Not Synced
    and in 2 seconds I will enter the PIN code
  • Not Synced
    What you see here are recovery codes,
  • Not Synced
    I will mention them in a few minutes.
  • Not Synced
    You can use them to recover your account
    if you lost your one-time password generator
  • Not Synced
    So, if I log in now,
  • Not Synced
    I have to use my smartphone to generate
    an authentication code, add it,
  • Not Synced
    and now I'm in, that's it.
  • Not Synced
    So it's pretty easy.
  • Not Synced
    Some people say "Oh, what if I lost
    my token, that is such much work."
  • Not Synced
    No, it's easy.
  • Not Synced
    If you want to recover your token,
    I do that all the time,
  • Not Synced
    you can just use SSH and do
    "ssh git@salsa.debian.org"
  • Not Synced
    and the command "2fa_recovery_codes"
    which will generate you
  • Not Synced
    a number of new recovery codes.
Title:
salsa.debian.org state of affairs
Description:

Talk given by Alexander Wirt at Minidebconf Hamburg 18
https://meetings-archive.debian.net/pub/debian-meetings/2018/miniconf-hamburg/2018-05-19/salsa.debian.org_state.webm

more » « less
Video Language:
English
Team:
Debconf
Project:
2018_mini-debconf-hamburg
Duration:
48:02

English subtitles

Incomplete

Revisions Compare revisions