forked from go-gitea/gitea
-
Notifications
You must be signed in to change notification settings - Fork 2
release-action
#2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
kousu
wants to merge
14
commits into
main
Choose a base branch
from
release-action
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+298
−106
Draft
Changes from all commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
09759b0
Workflow to build and release the current tag.
kousu 75aba36
Workflow to automatically sync with upstream.
kousu d2beaa8
Enable actuallying syncing all tags.
kousu b2d8c71
Trigger a build when pushing a new *-git-annex tag.
kousu 005fce1
Actually zero the release notes
kousu 41ff3af
--unshallow the upstream tags
kousu 5b803f6
Allow blank issues
kousu b6ac4a0
Bump to github-app-token 1.7.0
kousu 1d362d5
Bump actions.
kousu 2155044
Bump to go 1.19
kousu f99476e
Enable PAM builds
kousu fb21b92
lint
kousu e50657e
YAML lint
kousu 2dd57d1
Attempt to pare down tag release action to something that works
elhil File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,3 @@ | ||
blank_issues_enabled: false | ||
contact_links: | ||
- name: Security Concern | ||
url: https://tinyurl.com/security-gitea | ||
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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: | ||
kousu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
# 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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 action@github.com | ||
#- 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/github-app-token@v1.7.0 | ||
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://github.com/api/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://github.com/api/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 |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.