system-config/docker/gitea/custom/templates/home.tmpl
Clark Boylan 30279610b6 Update gitea to 1.21.3
Upgrade Gitea to 1.21.3. The changelogs for this release can be found
here:

  https://github.com/go-gitea/gitea/blob/v1.21.3/CHANGELOG.md

I have attempted to collect the interesting bits in this commit message
as well as information on why we do or don't make changes to address
these items.

1.21.0
 * BREAKING
   * Restrict certificate type for builtin SSH server (https://github.com/go-gitea/gitea/pull/26789)
     * We don't use the builtin SSH server and don't use certificates
       for auth. Nothing to do here.
   * Refactor to use urfave/cli/v2 (https://github.com/go-gitea/gitea/pull/25959)
     * The major change here updated `gitea` to stop accepting
       `gitea web`'s command options. Our dockerfile is set up to use
       `CMD ["/usr/local/bin/gitea", "web"]` so we are not affected.
   * Move public asset files to the proper directory (https://github.com/go-gitea/gitea/pull/25907)
     * We update the testinfra test for robots.txt to more robustly
       check file contents. Previously it checked a very generic
       prefix which may indicate a generic file being served.
     * We move custom/public/img into custom/public/assets/img.
       Screenshots should be used to confirm this works as expected.
   * Remove commit status running and warning to align GitHub (https://github.com/go-gitea/gitea/pull/25839)
     (partially reverted: Restore warning commit status (https://github.com/go-gitea/gitea/pull/27504) (https://github.com/go-gitea/gitea/pull/27529))
     * We don't rely on commit statuses as this is a read only replica
       of Gerrit.
   * Remove "CHARSET" config option for MySQL, always use "utf8mb4" (https://github.com/go-gitea/gitea/pull/25413)
     * We don't set [database].CHARSET. Doesn't affect us.
   * Set SSH_AUTHORIZED_KEYS_BACKUP to false (https://github.com/go-gitea/gitea/pull/25412)
     * We don't set this value explicitly so the default will flip from
       true to false for us. I don't think this is an issue because we
       keep track of our pubkeys in git.

 * SECURITY
   * Dont leak private users via extensions (https://github.com/go-gitea/gitea/pull/28023) (https://github.com/go-gitea/gitea/pull/28029)
     * We don't use private users.
   * Expanded minimum RSA Keylength to 3072 (https://github.com/go-gitea/gitea/pull/26604)
     * We have rotated keys used to replicate from gerrit to gitea to
       work around this. Now are keys are long enough to make gitea
       happy.

 * BUILD
   * Dockerfile small refactor (https://github.com/go-gitea/gitea/pull/27757) (https://github.com/go-gitea/gitea/pull/27826)
     * I've updated our Dockerfile to mimic these changes. Comment
       whitespace as well as how things are copied and chmoded in the
       build image have been updated.
     * TODO the file copies aren't working for us. I think due to how we
       ultimately clone the git repo. We use RUN but upstream is using
       COPY against the local build dir. I've aligned as best as I can,
       but we should see if we can do a similar COPY on our end.
   * Fix build errors on BSD (in BSDMakefile) (#27594) (#27608)
     * We don't run on BSD.
   * Fully replace drone with actions (#27556) (#27575)
     * This is how upstream builds their images. Doesn't affect our
       builds.
   * Enable markdownlint no-duplicate-header (#27500) (#27506)
     * Build time linters are somethign we don't care too much about on
       our end.
   * Enable production source maps for index.js, fix CSS sourcemaps (https://github.com/go-gitea/gitea/pull/27291) (https://github.com/go-gitea/gitea/pull/27295)
     * This emits a source map for index.js which can be used for in
       browser debugging. Don't think this is anything we need to take
       action on.
   * Update snap package (#27021)
     * We don't use a snap package.
   * Bump go to 1.21 (https://github.com/go-gitea/gitea/pull/26608)
     * Our go version is updated in the Dockerfile.
   * Bump xgo to go-1.21.x and node to 20 in release-version (https://github.com/go-gitea/gitea/pull/26589)
     * Our node version is updated in the Dockerfile.
   * Add template linting via djlint (#25212)
     * Build time linters are somethign we don't care too much about on
       our end.

1.21.1
 * SECURITY
   * Fix comment permissions (https://github.com/go-gitea/gitea/pull/28213) (https://github.com/go-gitea/gitea/pull/28216)
     * This affects disclosure of private repo content. We don't have
       private repos so shouldn't be affected.

1.21.2
 * SECURITY
   * Rebuild with recently released golang version
     * We'll automatically rebuild with newer golang too.
   * Fix missing check (https://github.com/go-gitea/gitea/pull/28406) (https://github.com/go-gitea/gitea/pull/28411)
     * There is minimal info here but it appears to be related to
       issues. We don't use issues so shouldn't affect us.
   * Do some missing checks (https://github.com/go-gitea/gitea/pull/28423) (https://github.com/go-gitea/gitea/pull/28432)
     * There is minimal info here but it appears to be related to
       checks around private repos. We don't use private repos so this
       shouldn't affect us.

1.21.3
 * SECURITY
   * Update golang.org/x/crypto (https://github.com/go-gitea/gitea/pull/28519)
     * This addresses recent concerns found in ssh for gitea's built in
       ssh implementation. We use openssh as provided by debian so will
       rely on our distro to provide fixes.

Finally 1.21.x broke rendering of code search templates. The issue is
here: https://github.com/go-gitea/gitea/issues/28607. To address this
I've vendored the two fixed template files
(https://github.com/go-gitea/gitea/pull/28576/files)into our custom
template dirs. Once upstream makes a release with these fixes we can
drop the custom files entirely as we don't override anything special in
them.

Change-Id: Id714826a9bc7682403afcf90f2761db8c84eacbf
2024-01-03 16:36:17 -08:00

215 lines
14 KiB
Cheetah
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

{{template "base/head" .}}
<div role="main" class="page-content home">
<div class="ui stackable middle very relaxed page grid">
<div class="sixteen wide center aligned centered column">
<div class="hero" id="opendev">
<img alt="OpenDev" class="logo" src="{{AssetUrlPrefix}}/img/opendev.svg" />
</div>
</div>
<div class="four wide center aligned centered column">
<div><img alt="Gitea" src="{{AssetUrlPrefix}}/img/git.svg" width="60"></div>
<a href="https://opendev.org/explore/organizations">Code hosting</a>
</div>
<div class="four wide center aligned centered column">
<div><img alt="Gerrit" src="{{AssetUrlPrefix}}/img/gerrit.svg" width="60"></div>
<a href="https://review.opendev.org/">Code review</a>
</div>
<div class="four wide center aligned centered column">
<div><img alt="Zuul CI" src="{{AssetUrlPrefix}}/img/zuul.svg" width="60"></div>
<a href="https://zuul.opendev.org/">Continuous integration</a>
</div>
<div class="four wide center aligned centered column">
<div><img alt="Etherpad" src="{{AssetUrlPrefix}}/img/etherpad.svg" width="60"></div>
<a href="https://etherpad.opendev.org/">Collaborative editing</a>
</div>
</div>
<div class="ui stackable middle very relaxed page grid">
<div class="sixteen wide left aligned centered column">
<h2 id="what-is-opendev">What is OpenDev?</h2>
<p>OpenDev is a collaboratory for open source software
development at scale. Its focus is on code review, continuous
integration, and project hosting provided exclusively through open source
solutions like Git, Gerrit, Zuul, and Gitea. It also provides a number of
peripheral collaboration services (like Mailman mailing lists, IRC bots for
notifications and annotating text-based meetings, Jitsi-Meet for
videoconference discussions integrated with Etherpad for collective text
editing). All of these services are openly operated by the community, and
continuously integrated and deployed using OpenDev itself.</p>
<h2 id="opendev-is-different">How is development different with OpenDev</h2>
<p>OpenDev doesn't use a pull request (or merge request)
workflow, like those implemented by GitHub or Gitlab. Instead it follows
Gerrit's iterative change proposal workflow, which results in a slightly
different experience.</p>
<p>In GitHub or Gitlab, contribution typically starts by
forking a personal copy of the original repository, cloning that locally, and
pushing one or more commits to that personal fork. Once your code seems ready
to merge, you ask the service to create a pull request for your branch into the
original repository. The pull request is reviewed, and if accepted your changes
get merged into the original repository. If not, you push more commits to your
fork and update the request seeking more reviews.</p>
<p>By contrast, contribution with Gerrit starts by cloning
the original repository locally. You iterate on development of one or more
local commits, and then use git push (or the git-review tool) to propose your
commits as a series of changes to the Gerrit code review service. Each change
in the series is reviewed, and if it's accepted (and passing tests) then it
gets merged into the original repository. If more work is needed, you amend
the same commits and push new versions of them for re-review.</p>
<p>The difference is subtle, but significant. In the
pull request model, you create a fork of the original repository, push
changes to it, and ultimately propose to merge changes back. In the change
proposal model, you prepare a change, and propose it. You do not create a
complete fork and everyone contributes into the same original repository with
what are basically lightweight, ephemeral topic branches. It results in less
fragmentation overall, and avoids confusion between the original repository and
its numerous forks.</p>
<p>That high-level difference also affects lower-level
details. A pull request may contain several commits, and if merged all those
commits will appear in the original repository history. In Gerrit, every commit
is a separate change (optionally depending on other related changes) for code
reviewers to review, so developers squash or amend edits made while developing
to represent the desired final state of that change. Each prior revision of a
change is still retained by the service, as are all the review comments, so
updates can be compared side-by-side for a clear picture of how the change
evolved. It generally results in easier code review, but also a cleaner branch
history with the commit messages reviewed as an integral part of each
change.</p>
<p>In summary, the Gerrit workflow, its user experience and
UI are different from the pull request workflow. While it may not be
immediately familiar to developers used to pull request workflows, it's worth
learning. Long-term benefits outweigh the short-term cost of having to learn a
new tool, especially for someone who is going to spend a lot of time developing
for that project anyway.</p>
<h2 id="integrated-ci">Integrated Continuous Integration</h2>
<p>One key benefit of OpenDev is that it integrates
powerful continuous integration features, made possible by the donation of
compute resources from our generous infrastructure partners. Test jobs are
run when changes are proposed and provide code reviewers with valuable
information. Test jobs also run again at merge time, in case recently approved
changes introduce an incompatibility, preventing code which doesn't pass tests
from merging to the repository.</p>
<p>Advanced Zuul features like speculative execution of
tests allow the testing of sequenced changes in parallel, so development
velocity is rarely limited by how thorough you want your tests to be. Changes
in one Git repository can depend on proposed changes in another repository,
allowing integration testing of features actively developed across multiple
projects, removing artificial barriers between development teams.</p>
<p>This advanced continuous integration system was
developed to sustain the complexity and scale of OpenStack development, one of
the three most actively developed open source projects in the world. OpenDev
makes this system available to other projects, enabling open development at
scale for everyone.</p>
<h2 id="free-tools">Free software needs free tools</h2>
<p>Finally, another key difference between OpenDev and
other development infrastructure services like GitHub or Gitlab.com is that
it's built purely using open source software. GitHub and Gitlab.com are
provided free of charge for open source projects, but they are both implemented
using proprietary code. If development of your free and open source software
requires interaction with proprietary code, is it truly free (as in
freedom)?</p>
<p>It is widely accepted today that using open source
technology reduces your reliance on outside parties and enables innovation. It
should be obvious that developing software by using open source toolchains has
the same effect. Nothing prevents a service provider from changing its terms of
service, creating new limitations, blocking access for contributors connecting
from specific countries, or even fully removing your project. Proprietary
development services create the same form of hard limits, lock-in and
dependency that proprietary software does, and prevent open innovation in the
development infrastructure space.</p>
<p>OpenDev is entirely built using open source software,
but goes one step beyond: it is also openly operated. Even its operation
tooling and configuration is open source, lives in Git, and is
continuously-deployed. It serves as a clear example of transparent
collaboration for systems administration. Like free and open source software,
it requires engaging with its community to get the most of it -- OpenDev is not
a service you consume, it's a community you join. That can be a bit
overwhelming if you just want to focus on development, especially when
ready-to-consume services are available. But it's worth it, especially if you
want to have a say in what services are provided, or just support the idea of
improving open source tools in that space.</p>
</div>
</div>
<div class="ui stackable middle very relaxed page grid">
<div class="sixteen wide left aligned centered column">
<h2 id="cloud-donors">Cloud Donors</h2>
<p>These are the companies generously donating the cloud infrastructure where we host our service control plane and operate <a href="https://docs.opendev.org/opendev/system-config/latest/contribute-cloud.html">pools of Zuul test resources</a>:</p>
</div>
<div class="four wide center aligned centered column">
<div><a href="https://openinfra.dev/a/members/profile/5/rackspace"><img alt="Rackspace" src="{{AssetUrlPrefix}}/img/donors/rackspace.jpg" width="120"></a></div>
</div>
<div class="four wide center aligned centered column">
<div><a href="https://openinfra.dev/a/members/profile/5/vexxhost-inc"><img alt="VEXXHOST, Inc." src="{{AssetUrlPrefix}}/img/donors/vexxhost.jpg" width="120"></a></div>
</div>
<div class="four wide center aligned centered column">
<div><a href="https://openinfra.dev/a/members/profile/5/ov-hcloud"><img alt="OVHcloud" src="{{AssetUrlPrefix}}/img/donors/ovh.jpg" width="120"></a></div>
</div>
<div class="four wide center aligned centered column">
<div><a href="https://openinfra.dev/a/members/profile/5/open-metal"><img alt="OpenMetal" src="{{AssetUrlPrefix}}/img/donors/openmetal.jpg" width="120"></a></div>
</div>
</div>
<div class="ui stackable middle very relaxed page grid">
<div class="sixteen wide left aligned centered column">
<h2 id="faq">FAQ</h2>
<h3 id="isnt-this-just-openstack-infrastructure-rebranded">Isnt this just OpenStack Infrastructure rebranded?</h3>
<p>It is more than that. We want to make this toolset
available to others that would find it helpful. OpenStack is one of the OpenDev
tenants, but other tenants like Zuul or $gizmo would be just as important.</p>
<h3 id="can-i-host-my-project-on-opendev">Can I host my project on OpenDev?</h3>
<p>Yes! However, as noted above it is still early days yet
and the early experience might be a bit bumpy. Certain things may still say
“OpenStack” on them as we figure out the transition. And while any moves should
come with appropriate redirects, we may have some inadvertent misses.</p>
<h3 id="can-i-run-tests-on-windows-or-osx-machines">Can I run tests on Windows or OSX machines?</h3>
<p>Currently all of our test resources are Linux based.
Adding additional platforms would likely require someone to help us get that
running, but Zuul will support systems with ansible connection plugins.
Talk to us!</p>
<h3 id="i-am-an-existing-openstack-infra-user-do-i-need-to-do-anything">I am an existing OpenStack Infra user do I need to do anything?</h3>
<p>No. Well continue to communicate changes as they
happen. Well also do our best to make this as smooth a transition as
possible. If we run into situations that force us to break something well
be sure to let you know at that point.</p>
<h3 id="is-a-cla-required-for-hosted-repos">Is a CLA required for hosted repos?</h3>
<p>No.</p>
<h3 id="what-if-i-dont-like-gerrit-and-would-prefer-insert-tool-here">What if I dont like Gerrit and would prefer (insert tool here)?</h3>
<p>Weve got a fair bit of experience with the existing
toolset and adding new tools for which weve already got an answer is currently
out of scope. We think the existing tools (like Gerrit) work well, and should
only get better as we update them. The system is able to scale because we do
not need multiple implementations of different software that solve similar
problems.</p>
<h3 id="why-cant-we-use-giteas-issue-tracker-and-wiki">Why can't we use Gitea's issue tracker and wiki?</h3>
<p>For scaling and redundancy purposes we are actually
running a number of independent Giteas behind a load balancer. We can keep
Git repos in sync from Gerrit reasonably well, but the issue tracker and
wiki functionality would need another level of state syncing. Once Gitea
can be run as a proper cluster this may change, but until then the
functionality is limited.</p>
<h2 id="contact-info">Contact info</h2>
<ul>
<li>IRC #opendev on OFTC (<a href="https://meetings.opendev.org/irclogs/%23opendev/">logs</a>)</li>
<li>Mailing list: service-discuss@lists.opendev.org (<a href="https://lists.opendev.org/mailman3/lists/service-discuss.lists.opendev.org/">subscribe</a>, <a href="https://lists.opendev.org/archives/list/service-discuss@lists.opendev.org/">archives</a>)</li>
<li>Important announcements: service-announce@lists.opendev.org (<a href="https://lists.opendev.org/mailman3/lists/service-announce.lists.opendev.org/">subscribe</a>, <a href="https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/">archives</a>)</li>
<li>Status updates on <a rel="me" href="https://fosstodon.org/@opendevinfra">Mastodon</a>
</ul>
<h2 id="service-vulnerabilities">Service vulnerabilities</h2>
<p>If you find or suspect a security issue with any OpenDev services, please inform the administrators via email at <a href="mailto:service-incident@lists.opendev.org">service-incident@lists.opendev.org</a>.</p>
</div>
</div>
</div>
{{template "base/footer" .}}