Skip to content

[Bioc-devel] Bioconductor Git: Online interface

3 messages · Martin Morgan, Henrik Bengtsson

#
I wanna revive this old thread.

I've used Gitea for internal git/issue trackers at the UCSF for quite
a while now and it works really well.  I've also looked into how easy
it would be to use it for pure code exposure and it's pretty
straightforward.  Gitea even has built-in tools for automatically
synchronize toward an existing git server *and* keep it up-to-date,
which makes the process even easier(*).  An example what this looks
like is:

  https://gitea.com/hb/aroma.light

That took me literally 15 seconds to set up.  Note how this is almost
a bare bone *read-only* git code browser, e.g. there's no issue
tracker.  Right now, it would require a teeny hack on the Gitea server
to have the 'git clone' URL to map to the official Bioconductor URL
(or to hide it completely).  It's also possible to link the 'Issue
Tracker' to, say, GitHub issues based on what's in BugReports:, e.g.

  https://gitea.com/hb/QDNAseq

Note that the above read-only approach completely avoids having to map
or maintain user accounts; it's a pure read-only online viewer of the
Bioconductor git repositories.  (Depending on your setup, it might
even be that you can expose the Gitea interface as
https://git.bioconductor.org/ and have
https://git.bioconductor.org/packages/<pkg> take you to the Gitea
package page.)  There's a Swagger API that makes it possible to
automate everything, e.g. creating new repositories for new Bioc
packages.

I'd classify this as a low risk and straightforward project to implement.

/Henrik

(*) Technical details: The most efficient approach would probably be
to link to the existing git repositories via the file system, rather
than going over ssh/https. Linking via the file system avoids any
duplication.  The storage load of running such a Gitea instance would
be very very small.  The Gitea instance don't need write permissions
to the repositories, so there is no risk of Gitea messing up existing
git repositories.

On Thu, Oct 26, 2017 at 1:51 AM Martin Morgan
<martin.morgan at roswellpark.org> wrote:
#
(sending again from / to an appropriate email address, sorry for the noise)

Henrik -- I appreciate the ease with which gitea can be deployed in this one-off solution but cynically think that a real deployment would introduce significant work, e.g., re-tooling our approach to new package addition, management of user credentials, and integration of the nightly build system.

If you'd like to work on a more complete (off-line, so as not to present a confusion of interfaces for the user and developer) implementation I'd be happy to provide some pointers to the major challenges.

Martin

?On 2/11/20, 5:16 PM, "Bioc-devel on behalf of Henrik Bengtsson" <bioc-devel-bounces at r-project.org on behalf of henrik.bengtsson at gmail.com> wrote:

    I wanna revive this old thread.
    
    I've used Gitea for internal git/issue trackers at the UCSF for quite
    a while now and it works really well.  I've also looked into how easy
    it would be to use it for pure code exposure and it's pretty
    straightforward.  Gitea even has built-in tools for automatically
    synchronize toward an existing git server *and* keep it up-to-date,
    which makes the process even easier(*).  An example what this looks
    like is:
    
      https://gitea.com/hb/aroma.light
    
    That took me literally 15 seconds to set up.  Note how this is almost
    a bare bone *read-only* git code browser, e.g. there's no issue
    tracker.  Right now, it would require a teeny hack on the Gitea server
    to have the 'git clone' URL to map to the official Bioconductor URL
    (or to hide it completely).  It's also possible to link the 'Issue
    Tracker' to, say, GitHub issues based on what's in BugReports:, e.g.
    
      https://gitea.com/hb/QDNAseq
    
    Note that the above read-only approach completely avoids having to map
    or maintain user accounts; it's a pure read-only online viewer of the
    Bioconductor git repositories.  (Depending on your setup, it might
    even be that you can expose the Gitea interface as
    https://git.bioconductor.org/ and have
    https://git.bioconductor.org/packages/<pkg> take you to the Gitea
    package page.)  There's a Swagger API that makes it possible to
    automate everything, e.g. creating new repositories for new Bioc
    packages.
    
    I'd classify this as a low risk and straightforward project to implement.
    
    /Henrik
    
    (*) Technical details: The most efficient approach would probably be
    to link to the existing git repositories via the file system, rather
    than going over ssh/https. Linking via the file system avoids any
    duplication.  The storage load of running such a Gitea instance would
    be very very small.  The Gitea instance don't need write permissions
    to the repositories, so there is no risk of Gitea messing up existing
    git repositories.
    
    On Thu, Oct 26, 2017 at 1:51 AM Martin Morgan
<martin.morgan at roswellpark.org> wrote:
>
    > There has been previous discussion about this.
    >
    >    https://stat.ethz.ch/pipermail/bioc-devel/2017-September/011455.html
    >
    > It is not in our short-term plans to offer a full on-line solution, but
    > not impossible in a longer context.
    >
    > Martin
    >
> On 10/26/2017 03:01 AM, Stian L?gstad wrote:
> > I would very much appreciate this as well. Issue tracking and communicating
    > > with users directly in the repository would be very nice, as well as the
    > > ability to reference source code directly.
    > >
    > > On Thu, Oct 26, 2017 at 8:50 AM, Henrik Bengtsson <
> > henrik.bengtsson at gmail.com> wrote:
> >
    > >> Are there any plans for an online interface to
    > >> https://git.bioconductor.org/?
    > >>
    > >> I've recently looked into solutions for an open-source in-house
    > >> "GitHub/GitLab"-ish, and I've found https://gitea.io/ to be really
    > >> nice.  It is very easy to install. It has support for various common
    > >> user authentication methods, it supports organizations and user teams,
    > >> repositories may have issues and wikis, sets of code lines can be
    > >> referenced, commits and code diffs are annotated, and so on.  Wikis
    > >> and issue trackers can be disabled (also for individual repositories).
    > >> That's all I've learned thus far - I'm impressed.
    > >>
    > >> Just a thought
    > >>
    > >> Henrik
    > >>
    > >> _______________________________________________
    > >> Bioc-devel at r-project.org mailing list
    > >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
    > >>
    > >
    > >
    > >
    >
    >
    > This email message may contain legally privileged and/or confidential information.  If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited.  If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you.
    
    _______________________________________________
    Bioc-devel at r-project.org mailing list
    https://stat.ethz.ch/mailman/listinfo/bioc-devel
#
On Tue, Feb 11, 2020 at 2:42 PM Martin Morgan <mtmorgan.bioc at gmail.com> wrote:
Among those examples, the only thing I see would be the workload of
adding/removing packages from Gitea so that it reflects what's on the
Git server.  Since Gitea can automatically sync with a Git server via
an URL, I don't see how things such as nightly builds etc come into
play.  User credentials should also not matter.  There should be no
backup needs other than possible one admin account with Swagger API
access.
I proposed Gitea because I know it well now, it has GitHub like
features that people already knows about (e.g. linking to code
snippets https://gitea.com/hb/aroma.light/src/branch/master/R/iwpca.R#L147-L152),
and it has the more potentials/features if you choose to go down that
route. I know there are other Git-to-webpage tools out there, which
are purely designed for viewing. It might be that those are a safer
route to go down. Given how easy it is to set up Gitea for this, and
Gitea has much more features, I'd be surprise if it wouldn't be as
easy for those tools too.  It could be that they're zero-config, e.g.
point to the folder where the git repositories live and you're ready
to go live.

Feel free to forward discussions/ideas (better if already public
somewhere; there might be others who can pitch in too), but
unfortunately I don't have much spare cycles to work on this.

Being able to browse code and link to code when reaching out to
maintainers is something Bioconductor is really missing right now.
This would lower the friction for contributing to packages that you
don't work on on a regular basis, e.g. typos, bug fixes, etc.

Henrik