@hermmm Sorry I didn't mean to click "disable auto-merge". Mistake. Let's re-enable it. 🙂
@hermmm Sorry I didn't mean to click "disable auto-merge". Mistake. Let's re-enable it. 
XRead my comment. Auto-merge is a new thing I think jorge turned on, and it requires the workflows to run. There's no other ways to merge.
AI am not sure. The repo's own existing workflow file should be the one that runs. It would be a literal exploit if I could submit a pull request where I change teh workflow to submit code to GHCR. I could literally make a PR to ublue-os/main that installs a virus if that were the case. 
So I dunno why it's not running the old workflow on the current PR! It should be running the old
Anyway, the changes are two things:
1. The publish to GHCR only happens if the branch is named
2. The auto-trigger workflows are changed to the following:
https://i.imgur.com/7EW7t9D.png
So I dunno why it's not running the old workflow on the current PR! It should be running the old
mainAnyway, the changes are two things:
1. The publish to GHCR only happens if the branch is named
live2. The auto-trigger workflows are changed to the following:
https://i.imgur.com/7EW7t9D.png
Imgur
XThe repo's own existing workflow file should be the one that runs. It would be a literal exploit if I could submit a pull request where I change teh workflow to submit code to GHCR.Hmm I wonder how PRs with changes to workflows are handled then...
AWhat this means is:
- Pull requests will only run builds when they target
- Cron schedule will run every branch every day.
- Pushes to branches will only run automatic builds if they target
- Any branch can manually trigger the workflow (that's
- Pull requests will only run builds when they target
live- Cron schedule will run every branch every day.
- Pushes to branches will only run automatic builds if they target
live- Any branch can manually trigger the workflow (that's
workflow_dispatch:).XI actually think that, since it's a PR coming from a branch outside the repo, it doesn't have the secrets and access, and thus can't push to GHCR.
XSo this PR might be running your workflow, actually.
AI dunno, it still makes no sense. The workflow inside the repo itself is the "action" that triggers.
X- Pull requests will only run builds when they target live.And this PR doesn't target live.
AHmm yeah it might be running MY local copy of the workflow instead of the upstream one i nstartingpoint.
XYeah the workflows and everything are in your repo.
AOkay that is good, that settles how workflows work in PRs. So they run in my local repo, not yours. Good security, phew.
XDo you even have the GHA enabled?
ANo. But I have some ideas how to fix this. We're gonna need some changes.
XAAh, yeah it's not visible there.
AI'm thinking atm, and will try to add
maintemplate to the auto-build targets.AAlternatively...
XWas just about to comment that.
XThen we'll just remove
mainWe could also just remove the list of branches to make every branch build no matter its name. Only
liveI am pretty sure this https://i.imgur.com/7EW7t9D.png list of
branches: was the old-school "protect against push to GHCR" idea before I changed it to only push liveWell, I don't know. If there's some in-repo development on a custom branch. I guess I should start making my PRs from a custom repo too to not pollute the template?
AI think removing
branches: filtering for the auto-build triggers would solve that. So that way every branch gets built no matter its name. We're exactly as safe as before, since the deploy/sign steps only run for liveAnd the builds seem to happen in the PR sender's own home.
XSure, do it. I guess stressing GHA shouldn't cause any issues.
AHmm, you make a point actually. Do we WANT anything except
template (main atm) and livePeople can still trigger manual builds on all other branches by manually triggering the workflow (that's the
workflow_dispatch: trigger).A
So... let's list main, template and live.XWell, we don't exactly want-want it but it shouldn't cause any issues.
AYeah. This solution sounds good, I'll refactor the docs a little bit around it.
XGreat
AI was just finished, but then I realized we may wanna do this:
- Pushes: Auto-builds on
- PRs: Auto-builds every branch, by removing the
- Pushes: Auto-builds on
livemaintemplate. As planned.- PRs: Auto-builds every branch, by removing the
branches: filter. This is what I just realized that we may need to do. Since it turned out that PRs run in the SOURCE repo/branch, not the target. So PRs from let's say branch: fix-foo -> merge into startingpoint:main would fail to run its GHA if we don't remove that filter. If PRs are working the way it seems.A@hermmm I found the issue. It's a bug that will affect every PR from old forks.
ALet's say people forked a while ago and their
That file is not properly setup to allow builds of branches.
So they make a branch
Their old
mainThat file is not properly setup to allow builds of branches.
So they make a branch
fix-something and submit it to you.Their old
mainfix-something and therefore nothing happens. 0 actions are listed.AI fixed it by fast-forwarding my own
mainSo PRs run the local
mainYes primary branch of the local fork workflow is what runs inside PRs. @j0rge may be very interested to hear this too.
AI converted the PR to a draft to stop the merge while I edit a comment that was misleading regarding this fact in build.yml.
XWe'll just have to instruct potential contributors with this issue to update their main branches
AYeah I added a note about that in build.yml too. It's ready for final check/merge.
AThis discovery also gives us another good reason why forks should keep an untouched "upstream main branch". Haha.
XTrue, 'xcept when working you'd probably want to set
liveOh yeah true, so they'd still have to rebase. Good thing my comment is phrased that way:
A"primary branch" is mentioned, phew.
AI was really surprised that PRs build using the fork's primary workflow. It feels very backwards, since that means upstream has no control over the workflow checks of PRs. I could then write a funny workflow that just succeeds instantly, and fool any upstream repo into accepting the "successful build".
ABut it makes some sense too, otherwise people could hog the upstream repo's build queue for their own PR spam.
ATo fix this, I really think GitHub should be using the fork's build queue + upstream's primary workflow. That'd be a good fix.
XYeah. But I'd've thought it at least used the divergent branch's workflow instead of the forks main branch's one
AYeah, that was the most nuts thing to me. Literally not even using the PR's own branch's workflow.
A@hermmm
