anyone here have experience creating flatpaks?
anyone here have experience creating flatpaks?
JI don't, but I found in the installer that it installs 0 flatpaks, so when we make an ISO we don't have to rip out stuff, we can just add what we want, which will be a welcome change, heh
DAfaik some of xfce apps is already available on flathub
Jmaybe we can drum up some support "vauxite is looking for help flatpakking up some xfce apps, anyone wanna help?" or something?
D@theevilskeleton
Hyeah there's like two or three of them.
HI think I can figure it out on my own. Shouldn't be rocket science or anything. I'll look for docs on creating flatpaks.
Hsorry I'm kinda out of the loop on this...how do we make ISOs?
TI do
TIs MenuLibre an XFCE app? I maintain it
TWell, "maintain"
Jwe're waiting on 2 PRs upstream: https://github.com/orgs/ublue-os/discussions/26#discussioncomment-5056191
GitHub
Can I make an ISO from a fork of this repo?
Jthen we can just ship a preconfigured kickstart file right on the iso
Hah, nice
MWe've been chewing through the "PRs can't push" with @j0rge we're close to a new workflow but it's getting late and we'll pick it up in the morning.
Jtldr it was designed to not allow us to do that on purpose for security reasons, so we had to figure out how to do it in a way that enables us to review before building
Jso tldr, when a PR comes in nothing will happen, after you check it and you want to test it you as a maintainer can add the label
ok-to-test to the PR, then the actions kick inJthen it makes and pushes a
pr-27Jor whatever the PR is
Bit makes sense for them to not allow pushes from PRs action runs, that could be a nightmare
REven with this, you've got to take into account that anybody can change the workflows in their PRs. If you give PRs permissions to push to GHCR, you're also giving permissions for PRs to push images with the :latest tag.
The safest way would be to require approval on all commits, and not manage this through a workflow.
https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
The safest way would be to require approval on all commits, and not manage this through a workflow.
https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
MWorkflow changes only take effect after merging to main
MWe tested this yesterday to confirm
RAh, you've already enabled the setting that all workflows require approval
https://github.com/ublue-os/experimental/pull/21
https://github.com/ublue-os/experimental/pull/21
MHeh, the experimental repos GHA doesn’t build on PR
MIt also limits only for first time contributors
MWe also are using an “ok-to-build” label system - but that only works if you can’t modify it during PR
RPlease can you try approving this workflow
https://github.com/ublue-os/experimental/actions/runs/4292680387
https://github.com/ublue-os/experimental/actions/runs/4292680387
M
MWell
MThis didn’t work last night
MThis whole saga is probably one of the more frustrating things I’ve come across in recent memory
MGuess we’ll need to use that additional button for approving an action run
BHonestly i would have seperate workflow for prs
BThat just doesnt push
MThat means we cant rebase to test pr easily
MIt’s a huge bonus for reviewers to have a VM to validate changes IRL
RI know it's not ideal, but unless you're planning on using AWS ECR or some other service with fine-grained access controls, I don't see how you can limit this.
With ECR, you can "assume" roles only from specific branches, and each role can only create images with specific tags.
So a
A
Or just keep the approval button for all forked workflow runs/don't push in PRs.
With ECR, you can "assume" roles only from specific branches, and each role can only create images with specific tags.
So a
production role is only assumable by the main branches, and this role can create latest tags.A
development role is assumable by all branches, and can create pr-* tags.Or just keep the approval button for all forked workflow runs/don't push in PRs.
MI think approval button for now
MDoesn’t need to be perfect just needs to work and we can figure out and iterate over time
Jok so what are we doing?
RI think create a PAT which can write to packages, then require all workflows to be approved by a maintainer.
The PAT will be used during the
The PAT will be used during the
docker login step, and allow PRs to push once a maintainer has approved the code is not malicious.Jok so an approval button instead of adding a label?
RBy requiring approval, i mean this.
The label wouldn't work as the logic in the workflow that checks if the label exists can be edited by any PRs created from forks.
The label wouldn't work as the logic in the workflow that checks if the label exists can be edited by any PRs created from forks.
Joh, ok that looks fine to me, we're on the middle setting now, which is what it defaulted to
RAt the minute, that's fine since there's no PAT which allows pushing to GHCR from forks
Jall the docs we've been reading are recommending against a PAT
JI guess that's the old way to do it?
RUsing GHCR, I think it's the only way. But you're only using the PAT on workflows you've already checked, so it's much safer than allowing all PRs to use the PAT
Bon github actions if you are using GHCR you shouldnt use a PAT
RBut we can't use the default GITHUB_TOKEN since it doesn't have permissions on forked workflows.
What other options are there?
What other options are there?
