82 Replies
ehrm what the sigma
ok so
oh nice we might be able to just use that then on the gh actions
I mean there is this https://packit.dev/docs/reproduce-locally
Reproduce CI environment locally | Packit
This used to be a question in our FAQ and
But maybe there is a way to trigger remote builds
lets just use the hosted stuff they have
im guessing packit-cli lets us trigger the builds
:huh: So what i said
real
didnt read it
just packit-shell and elts start diggingoh there yo go
packit build in-copr
oh it absolutely works?
Does it show in github or something?
packit build in-copr --package aurora
failed thommm
oh we also might want to add a packit lint thing then
on packit config change
why is this god damn thing failing tho
Something during the rebase
yep, work in my backup branch
wondeful ðŸ˜
copy over ur packit config from the backup branch
then just commit as a new one
LOL
by any chance do you have git rerere disabled?
yup
:v
no idea what that is
It remembers rebase conflict solutions
Have a video but lets focus on this first
oh i do
i have it
rerere.enabled=true
huh
do you mind pushing ur functioning config to the remote branch?
i wanna test it out
its on my packit-efficient-trigger-bak branch
git checkout .packit.yml packit-efficient-trigger-bak
i thinkoh
from the non-bak branch
k did, but 0 changes
wait now works
whats ur command line
ok so no this only triggers locally
yeah
damn
ooooh
in-copr | Packit
Submit a Copr build of the present content in the upstream repository.
lets just go with the god damn comments for now
fuck it
mmmThat requires us storing the token as a secret
yeah fuck that
gonna take a break and keep going with the comment thing
so what are we missing with the comment stuff?
i can work on it while ur on the break
oh um i think the workflow isnt running cuz you dont have branch perms on the thing
maybe i can PR it from the ublue-os/packages repo itself
mmm I think is almost done
GitHub
feat: add packit with automated building by tulilirockz · Pull Req...
This is @Zeglius 's PR #337 but on ublue-os/package's github context so we can run the workflows on the incoming PR
?
Why a separate pr?
incoming PRs from other contexts need some funky shit to run
like
new workflows
due to security reasons
(you dont want people just adding a workflow then fucking adding a crypto miner on ur actions or something)
i just made a new PR from a branch on the
ublue-os/packages repo
so the new workflow will run
i can just rebase mine when you make a new change
then i close mine when we know its all working goodah okay
Oh k so the action actually runs
seems to get skipped tho
oh wait nvm mixed it with the current one
Yeah probably because no package was changed
also is missing the packit-run label
Alright gonna try with a dummy commit on a package and see if triggers
i gotta just rebase mine
ok done, try rebasing
goig to my pc
nvm is working in my pr
hell yeah
wait
there was no comment
AH no its yours
yea i need to um
rebase
also remove the frankenstein thing
yeah i need that break smh
kill it with fire now that we dont need to use it no more
OH SHIT IT WORKED LES GOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
@Zeglius
the workflow
but the comment failed....
i think we need a write perm on something else
content: write?
Okay so good, it triggers with comments made with an action
But bad because now we need a separate account linked to fedora auth thingy
you sure?
"account has no write access"
what does that mean
oh shit LOL
also the "get all changed packages" thiung broke
regardless of that, there is a worse issue
the bot doesnt interpret --package flag in gh comments
i think we want to just use the packit-cli thing
Ok but does it trigger the check runs in github is the question
first we need to try doing it locally and see if it shows up
i mean, it'll show as an action workflow
doing that right now locally
where?
just like any other action thing
there wont be that cool "packit package thingmie"
No I mean where did show up for you?
lioke this
so you still end up using github runners
ya
its fine by me tbh
it wont build locally
On top of that now you need to store secrets for the api token
i mean
we cant... not use that
Also we still are vulnerable to secret leaks that way
shrug
At that point why even using packit
for the copr stuff
like i dont know how we'll get over this shit
i think we should use the frankenstein and have a separate bot account on our copr
for triggering new builds
OH
@Zeglius we can just use copr cli with an account that has just enough privileges to build the packages
we need the secret should always be replaceable anyways so even if we leak it it should be fine
you would still want to use packit for the ephemeral coprs
we can create a testing copr for each one on the workflow
copr create packages_test then put all the builds there
on like ublue-os-bot or somethingNo
I refuse to reinvent the wheel
blud we cant use the wheel
the wheel is just square shaped for us
Just replace the frankeinstein to use the _list_changed_packages recipe instead and done
we need smooth round wheels
Gonna ask in in the matrix channel if we can somewhat trigger individual builds other than by comments
aight!
lwts see if we can get it going
worst case we'll just improve on our own shit
@tulip🌷 btw if we can make the pr checks to only see if the matching package is building we are good then
We trigger all the builds? Well, not my issue, should have they added filters for that alongside the mono repo support