forked from go-gitea/gitea
-
Notifications
You must be signed in to change notification settings - Fork 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
release-action
#2
Draft
kousu
wants to merge
13
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.
Draft
Conversation
This file contains 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
kousu
force-pushed
the
release-action
branch
2 times, most recently
from
March 26, 2022 19:37
3a195d7
to
9c96725
Compare
kousu
force-pushed
the
main
branch
2 times, most recently
from
March 26, 2022 20:36
3435ec1
to
ded2781
Compare
github-actions
bot
force-pushed
the
main
branch
2 times, most recently
from
March 27, 2022 09:11
b24a462
to
65e42f8
Compare
kousu
force-pushed
the
release-action
branch
6 times, most recently
from
March 28, 2022 04:01
6c9b8d2
to
3103f8a
Compare
kousu
force-pushed
the
release-action
branch
14 times, most recently
from
March 28, 2022 06:46
2a77c13
to
bf10d4c
Compare
gitea-sync
bot
force-pushed
the
release-action
branch
6 times, most recently
from
November 2, 2023 13:11
b3a16da
to
61c6aad
Compare
gitea-sync
bot
force-pushed
the
release-action
branch
7 times, most recently
from
November 11, 2023 13:09
573aefd
to
290201e
Compare
gitea-sync
bot
force-pushed
the
release-action
branch
2 times, most recently
from
November 13, 2023 13:12
61906de
to
e68300b
Compare
This only runs on tags that include this file, so it won't run on any upstream tags, but only on tags into which this has been merged/cherry-picked.
We plan to keep this fork alive for a significant amount of time, because it will hold an extra feature (#1) that upstream doesn't have. Automate keeping up to date with upstream to reduce our overhead. The scheme I chose for this is a little bit convoluted. There are three branches involved, but this means that the patch that we might potentially upstream is clean. Also, this scheme can't fix merge conflicts automatically, but it can find and email about them automatically, which is about as good as we can hope for.
fetching the latest tag with --depth 1 fails: that makes a shallow commit (aka a 'grafted' commit) and github refuses to accept it when being pushed back. Instead, use --shallow-exclude=HEAD which seems to get enough of the history without getting *all* of the history that github will accept the upload
We need a special token, given to us by tibdex/github-app-token, because the default token that workflows are given is constrained: > 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. > For example, if a workflow run pushes code using the repository's > GITHUB_TOKEN, a new workflow will not run even when the repository > contains a workflow configured to run when push events occur. - https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow See also https://github.community/t/push-from-workflow-not-doesnt-trigger-on-push-tags-workflow/149151/2 GitHub recommends https://docs.github.com/en/actions/using-workflows/reusing-workflows#calling-a-reusable-workflow for solving this, but that seems a lot less flexible to me. I'd rather be able to choose whether to trigger a build by pushing a tag manually or having the bot do it.
Fixes this failure: https://github.com/neuropoly/gitea/runs/7042433953?check_suite_focus=true Also, expand the comments, now that I understand this better.
For us, as a fork working on our own bubble, these are useful
Gitea's official builds have this disabled. I'm not sure why. But I would like to use it at least on some neurogitea systems, so turn it on. See https://docs.gitea.io/en-us/authentication/#pam-pluggable-authentication-module
gitea-sync
bot
force-pushed
the
release-action
branch
from
November 14, 2023 13:12
e68300b
to
e50657e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This contains the build scripts ("release engineering") for #1.
release.yml
- build; this is basically just a stripped down port of what's in.drone.yml
onto Github Actionssync-upstream.yml
- a helper to make tracking; pulls upstream, and tries to merge it withgit-annex
#1 and with their most recent release (and then builds that)It's in a separate branch to avoid polluting either
main
orgit-annex
.And this is now the default branch in this repo, in order to take advantage of Actions cronjobs which only run on the default branch.
This PR is not designed to be merged. It could be, but the script within it would have to drop the section that updates itself, and then we wouldn't have a 100% clean mirror of upstream to rebase against.