release-action

.github/ISSUE_TEMPLATE/config.yml

@@ -1,4 +1,3 @@
-blank_issues_enabled: false
 contact_links:
   - name: Security Concern
     url: https://tinyurl.com/security-gitea

.github/workflows/release.yml

@@ -0,0 +1,61 @@
+name: Release
+
+on:
+  push:
+    tags:
+      - "v*.*.*"
+
+  # This second trigger covers the case where you
+  # delete and recreate from an existing tag
+  release:
+    types:
+      - created
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+
+      - name: Install toolchain
+        run: |
+          sudo apt-get update && sudo DEBIAN_FRONTEND=noninteractive apt-get install -y make git xz-utils libpam0g-dev
+      # per README.md, building needs Go 1.19 and Node LTS
+      - uses: actions/setup-go@v3
+        with:
+          go-version: '^1.19' # The Go version to download (if necessary) and use.
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 'lts/*'
+
+      - name: Build Release Assets
+        # The officially releases use 'make release' (https://github.com/neuropoly/gitea/blob/65e42f83e916af771a51af6a3f8db483ffa05c05/.drone.yml#L772)
+        # but that does cross-compilation (via docker (via https://github.com/techknowlogick/xgo))
+        # which is overhead and complication I don't need or want to deal with.
+        #
+        # Instead, just do native Linux compilation then pretend we did 'make release'.
+        run: |
+          TAGS="bindata sqlite sqlite_unlock_notify pam" make build
+          mkdir -p dist/release
+          cp -p gitea dist/release/gitea-"$(git describe --tags --always)"-linux-amd64
+
+      - name: Compress Release Assets
+        run: |
+          xz -k dist/release/*
+
+      - name: Checksum Release Assets
+        # each release asset in the official build process gets a separate .sha256 file
+        # which means we need a loop to emulate it
+        run: |
+          (cd dist/release; for asset in *; do sha256sum "$asset" > "$asset".sha256; done)
+
+      - name: Upload Release
+        # this Action creates the release if not yet created
+        uses: softprops/action-gh-release@v1
+        with:
+          # We don't have .drone.yml's pretty changelog
+          #  generator, so just empty the release notes
+          # ('' doesn't work, it needs at least one character)
+          body: '.'
+          files: 'dist/release/*'
+          fail_on_unmatched_files: true

.github/workflows/sync-upstream.yml

@@ -0,0 +1,235 @@
+# This soft-fork of Gitea adds git-annex support (https://git-annex.branchable.com/)
+# git-annex is like git-lfs, which Gitea already supports, but more complicated,
+# except that it doesn't need an extra port open.
+#
+# We maintain three branches and N tags:
+# - main           - a mirror of upstream's main
+# - git-annex      - our patch (see it at: https://github.com/neuropoly/gitea/pull/1)
+# - release-action - release scripts + our front page
+# - $X-git-annex for each upstream tag $X (each created after we started tracking upstream, that is)
+#     which = $X + release-action + git-annex
+#
+# This branch, release-action, contains:
+#  - sync-upstream.yml (this)  - try to update the branches/tags
+#  - release.yml               - build and push to https://github.com/neuropoly/gitea/releases/
+# and it is our default branch because cronjobs are
+# only allowed to run on the default branch
+
+name: 'Sync Upstream'
+
+on:
+  workflow_dispatch:
+  schedule:
+    # 08:00 Montreal time, every day
+    - cron: '0 13 * * *'
+
+jobs:
+  sync_upstream:
+    name: 'Sync Upstream'
+    runs-on: ubuntu-latest
+    steps:
+
+      #- name: debug - github object
+      #  run: |
+      #    echo '${{ tojson(github) }}'
+
+      - name: Git Identity
+        run: |
+          set -ex
+          git config --global user.name "Actions Bot"
+          # or 41898282+github-actions[bot]@users.noreply.github.com ?
+          git config --global user.email [email protected]
+
+      #- name: Git config
+      #  run: |
+      #    set -ex
+      #    # disambiguates 'git checkout' so it always uses this repo
+      #    #git config --global checkout.defaultRemote origin
+
+      - id: generate_token
+        # The default token provided doesn't have enough rights
+        # for 'git push --tags' to trigger the build in release.yml:
+        #
+        # > When you use the repository's GITHUB_TOKEN to perform tasks, events
+        # > triggered by the GITHUB_TOKEN will not create a new workflow run.
+        # > This prevents you from accidentally creating recursive workflow runs.
+        #
+        # ref: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow
+        #
+        # But we're not making a recursive workflow, and really do want to
+        # trigger the release.yml workflow.
+        #
+        # https://github.com/tibdex/github-app-token works around this by
+        # trading OAuth credentials (created at the Organization level) for
+        # a token credential (which can't be created except at the user level)
+        #
+        # Two alternate solutions are:
+        #
+        # 1. Provide a personal token (https://github.com/settings/tokens) but then
+        #    whoever does exposes their account to everyone in the organization,
+        #    and the organization is exposed to DoS if the person ever leaves.
+        # 2. Use workflow_call: (https://docs.github.com/en/actions/using-workflows/reusing-workflows)
+        #    but this is a substantial amount of intricate code
+        #    for something that should be simple.
+        #
+        # If you need to reconfigure this, know that you need to:
+        #
+        # 1. Create an OAuth credential at https://github.com/organizations/neuropoly/settings/apps
+        #   a. Set 'Name' = 'gitea-sync'
+        #   b. Set 'Homepage URL' = 'https://github.com/neuropoly/github-app-token'
+        #   c. Uncheck 'Webhook'
+        #   d. Set 'Repository permissions / Contents' = 'Access: Read & write'.
+        #   e. Set 'Where can this GitHub App be installed' = 'Only on this account'
+        # 2. Click 'Generate Private Key'; it will download a .pem file to your computer.
+        # 3. Store the credential in the repo at https://github.com/neuropoly/gitea/settings/secrets/actions
+        #    a. Set 'APP_ID' = the app ID displayed on https://github.com/organizations/neuropoly/settings/apps/gitea-sync
+        #    b. Set 'APP_KEY' = the contents of the .pem file it downloaded.
+        #    c. Now you can throw away the .pem file.
+        # 4. Install the app:
+        #    a. Go to https://github.com/organizations/neuropoly/settings/apps/gitea-sync/installations
+        #    b. Click 'Install'
+        #    c. Pick this repo
+        #    d. Click 'Install' for real this time
+        #
+        # ref: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens
+        #
+        # Notice too: we've **forked** a copy of tibdex/github-app-token,
+        # to avoid passing our tokens through potentially untrusted code.
+        # Even if it is safe now, it might become malicious in the future.
+        uses: neuropoly/[email protected]
+        with:
+          app_id: ${{ secrets.APP_ID }}
+          private_key: ${{ secrets.APP_KEY }}
+
+      - uses: actions/checkout@v3
+        with:
+          token: ${{ steps.generate_token.outputs.token }}
+
+      - name: Add upstream
+        run: |
+          set -ex
+
+          PARENT=$(curl -s https://api.github.com/repos/${{github.repository}} | jq -r '.parent.clone_url // empty')
+          git remote add upstream "$PARENT"
+
+      - name: Fetch current origin
+        run: |
+          set -ex
+          # Because actions/checkout does a lazy, shallow checkout
+          # we need to use --shallow-since to make sure there's
+          # enough common history that git can tell how the two
+          # branches relate.
+          #
+          # We *could* do a full checkout by setting depth: 0 above,
+          # but this is faster, especially on a large repo like this one.
+          #
+          # Since this runs daily, 1 week should be plenty.
+          git fetch '--shallow-since=1 week' origin main "${{ github.ref_name }}" git-annex
+          git fetch '--shallow-since=1 week' upstream main
+
+      - name: Sync main
+        # force main to be identical to upstream
+        # This throws away any commits to our local main
+        # so don't commit anything to that branch.
+        run: |
+          set -ex
+          git checkout -B main upstream/main
+
+      - name: Sync ${{ github.ref_name }}
+        run: |
+          set -ex
+          git checkout "${{ github.ref_name }}"
+          git rebase main
+
+      - name: Rebase git-annex, the feature branch
+        # This is the meatiest part of this script: rebase git-annex on top of upstream.
+        # Occasionally this step will fail -- when there's a merge conflict with upstream.
+        # In that case, you will get an email about it, and you should run these steps
+        # manually, and fix the merge conflicts that way.
+        run: |
+          set -ex
+          git checkout git-annex
+          git rebase main
+
+      - name: Construct latest version with git-annex on top
+        id: fork
+        run: |
+          # for the latest tag vX.Y.Z, construct tag vX.Y.Z-git-annex.
+          # Only construct the *latest* release to reduce the risk of conflicts
+          # (we have to ask 'git tag' instead of the more elegant method of syncing tags
+          #  and using Github Actions' `on: push: tags: ...` because those upstream tags
+          #  *don't contain this workflow*, so there would be no way to trigger this)
+          #
+          # This will trigger release.yml to build and publish the latest version, too
+          set -e
+
+          # git fetch is supposed to get any tags corresponding to commits it downloads,
+          # but this behaviour is ignored when combined with --shallow, and there doesn't
+          # seem to be any other way to get a list of tags without downloading all of them,
+          # which effectively does --unshallow. But the GitHub API provides a shortcut, and
+          # using this saves about 30s over downloading the unshallow repo:
+          PARENT_API=$(curl -s https://api.github.com/repos/${{github.repository}} | jq -r '.parent.url // empty')
+          PARENT_TAGS=$(curl -s "$PARENT_API"| jq -r '.tags_url // empty')
+          RELEASE=$(curl -s "$PARENT_TAGS" | jq -r 'map(.name | select(test("dev") | not)) | first // empty')
+
+          # But if we decide to just unshallow the entire repo from the start,
+          # then you can use this instead:
+          #RELEASE="$(git tag -l --sort=-v:refname | egrep -v 'git-annex$' | head -n 1)"
+
+          if git fetch -q --depth 1 origin tag "$RELEASE"-git-annex 2>/dev/null; then
+            echo "$RELEASE-git-annex already published :tada:"
+          else
+            set -x
+            # BEWARE: the releases are tagged off of *release* branches:
+            #         https://github.com/go-gitea/gitea/tree/release/v1.18
+            #         https://github.com/go-gitea/gitea/tree/release/v1.17
+            #
+            #         These were branched from 'main' at some point, and since
+            #         have been added to with backport patches. For example,
+            #         https://github.com/go-gitea/gitea/pull/19567 is the backport
+            #         into v1.16 of https://github.com/go-gitea/gitea/pull/19566.
+            #         In that case, the two patches were identical, but it's possible
+            #         a merge conflict could force edits to the backport.
+            #
+            #         To fit into their scheme, we would have to manuually maintain
+            #         our own git-annex branch (based on upstream/main), another
+            #         release/v1.18-git-annex (based on upstream/release/v1.18), and a
+            #         release/v1.17-git-annex (based on upstream/release/v1.17), etc.
+            #
+            #         That seems like a lot of work, so we're taking a shortcut:
+            #         just cherry-pick main..git-annex on top of their releases
+            #         and hope for the best.
+            #
+            #         The only trouble I'm aware of with this is that a merge conflict
+            #         will show up against upstream/main but might not exist against
+            #         v1.19.1 or whatever the latest tag is; so fixing it for main will
+            #         cause a different merge conflict with the release.
+            #
+            #         But we only need each release to get tagged and published once
+            #         (see: the if statement above), so the best way to handle that case
+            #         is to manually fix the conflict against upstream/main, and at the
+            #         same time manually tag the latest release without the additional fixes.
+            #         This is basically the same work we would do anyway if we were manually
+            #         backporting every update to a separate release branch anyway, but
+            #         only needs to be investigated when the automated build fails.
+            #
+            #         tl;dr: If this step fails due to merge conflicts, you should
+            #         manually fix them and then manually create the tag,
+            #         sidestepping this
+
+            # Because the tags don't share close history with 'main', GitHub would reject us
+            # pushing them as dangling commit histories. So this part has to be --unshallow.
+            # It takes longer but oh well, GitHub can afford it.
+            git fetch --unshallow upstream tag "$RELEASE"
+
+            git checkout -q "$RELEASE"
+
+            git cherry-pick main.."${{ github.ref_name }}"  # Make sure release.yml is in the tag, so it triggers a build
+            git cherry-pick main..git-annex
+
+            git tag "$RELEASE"-git-annex
+          fi
+      - name: Upload everything back to Github
+        run: |
+          git push -f --all
+          git push -f --tags