Skip to content
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
wants to merge 13 commits into
base: main
Choose a base branch
from
Draft

release-action #2

wants to merge 13 commits into from

Conversation

kousu
Copy link
Member

@kousu kousu commented Mar 26, 2022

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 Actions
  • sync-upstream.yml - a helper to make tracking; pulls upstream, and tries to merge it with git-annex #1 and with their most recent release (and then builds that)

It's in a separate branch to avoid polluting either main or git-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.

⚠️ If you want to work on this branch, make sure to keep in sync with the automatic updates by:

git checkout git-annex
git pull --rebase

@gitea-sync gitea-sync bot force-pushed the release-action branch 6 times, most recently from b3a16da to 61c6aad Compare November 2, 2023 13:11
@gitea-sync gitea-sync bot force-pushed the release-action branch 7 times, most recently from 573aefd to 290201e Compare November 11, 2023 13:09
@gitea-sync gitea-sync bot force-pushed the release-action branch 2 times, most recently from 61906de to e68300b Compare November 13, 2023 13:12
kousu and others added 13 commits November 14, 2023 13:11
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant