Community
Chat Logs
Saturday, October 24, 2026 (America/New_York)
- phaleththe VPS got beefier
- phalethflog trust me bro script now works, but primate repo has some old version of flog.lock
- phalethflog: error: /home/user/primate/primate/flog.lock: unsupported flog.lock version 0 (expected 1)
- phaleththere is a change in the making https://repopack.com/project/primate/tasks/236#flog.lock
- phalethhere just use buildkit already, the deamon is running on the VPS and is managed by systemd https://repopack.com/project/repopack/tasks/737 no need to do any short term solution, buildah is inferior
- bluehi phaleth
- phalethdamn, cannot force push
- phalethand git fetch git pull isn't getting the commits I've reset locally
- bluewhere, phaleth?
- phalethcannot force push to a feature branch
- phaleththat's too restrictive
- phalethI mean task branch
- bluewhy would you wanna force push to a task branch?
- bluejust add commits on top. it all gets squashed in the end anyway
- phalethwhen screwing up something and not wanting to make another commit, git commit --amend is a thing for a reason
- phalethyeah, but for the reviewer it's pain in the butt if they review locally, which they should
- bluethe problem with amending commits on a task branch is that it rewrites history. it's probably ok as long as the task is in ACTIVE, but after it's been submitted to a REVIEW, it's weird
- blueI'll see if I can create a task for it that makes sense
- blue"I think you and phaleth are talking past each other. Repopack already permits a force-push to a task branch by its owner while the task is active—including after git commit --amend. It rejects pushes during review or ready; the owner must run rp task revise <number> before changing a submitted branch. Other users, including maintainers, cannot push to someone else’s task branch without an ownership
- bluehandoff."
- blueshould be working for you phaleth
- phalethwell I'm forced to do `rp task revise` anyway
- blue"His fetch/pull problem may be separate. If he reset away local commits that were never pushed, fetching cannot recover them; git reflog may. If they were pushed, we need the exact branch, task status/owner, and Git rejection text to tell why the push failed. I wouldn’t create a policy-change task yet—first ask him for those details."
- phalethok so that means I didn't revise
- blueyes
- phalethbut can the error tell me to do revise in some more understandable way?
- bluewhat error did you get?
- phalethafter amend I did this https://paste.debian.net/plainh/2a2daa96
- phalethand it suggested nonsense so I executed that and obviously got rejected
- phalethhow can I tell primate website image build on repopack site to use specific arg? ARG FLOG_VERSION="0.1.0"
- phalethyou've mentioned 0.1.1 is released
- blueyes
- blueyou can configure args on a job
- phalethvia CLI? ok
- bluerun `rp job args` or `rp job args --help`
- bluegenerally: rp job args add <number> FLOG_VERSION
- blueyou can add a default with --default; if you don't, the arg is required
- blue<number> is the job number
- blueobviously you'd need to edit the Containerfile, but you know that
- phalethok, cool
- blueto provide the arg during run, use --build-arg
- blue→ rp job run
- blueusage: rp job run <job-number> [--source <ref>] [--build-arg NAME=VALUE]... [--attach]
- phalethwait, not for job, but for app
- phalethfor containerized deployment
- bluephaleth: there's already `rp task push .`. but you need a flag for force-push, as well
- bluehow about:
- bluerp task push . --replace-head
- bluethat good?
- phalethrp app args is not a thing
- phalethrp task push --force-with-lease
- blueyou need the .
- phalethrp task push <number> --force-with-lease
- blueand --force-with-lease is git terminology, I'd prefer we use something saner
- phalethwhat does the . mean there?
- phalethheh
- blue. means "the task branch I'm currently on"
- phalethoh :D
- phalethok, good to know
- blueit saves you remember the number
- blueremembering*
- phalethyeah
- phalethwell, alright no args passed to the deployment
- blueyeah, I need to see if we can add args to app deployment as well
- blueI'm gonna go with --replace-head, unless you have a better suggestion. but --force-with-lease means nohting to me, git has terrible DX
- phalethhttps://repopack.com/project/primate/tasks/238
- phaleththat's the usecase
- phalethyeah, but how can I remember --replace-head unless the error message tells me
- phaleththe problem is that the error message is suggesting wrong thing to do
- phalethand also nothing about revise
- bluehold on
- phalethyeah, no hurry
- bluephaleth: https://repopack.com/project/repopack/tasks/740
- blueis that ok?
- blue" A task in review, ready, or revision must give a direct rp task revise <number> instruction before a rewrite."
- blueI can do it now and release a new rp. I've been meaning to release a new rp anyway today
- blueprobably will be a 0.2.0
- phalethno idea, looks like a wall of text to me
- phalethnot sure if it says the user will be told to revise the task
- phalethlooks like it does not, so it's just spewed a lot of nonsense it seems
- blue12:23 < blue> " A task in review, ready, or revision must give a direct rp task revise <number> instruction before a rewrite."
- phalethalso clanker just spewed what I mentioned before at me here https://repopack.com/project/rcompat/tasks/86
- phalethyeah, that does not say user will be told about revise in error message
- phalethdoes the trust me bro script accept version as arg?
- blueyou mean flog.sh/install ?
- phalethyeah, looks like it does and that's what clanker means
- blueflog.run/install *
- phalethPass FLOG_VERSION="$FLOG_VERSION" to the installer command itself
- phalethI feel like getting dummier and dummier the more I work with clanker
- bluephaleth: the problem with https://repopack.com/project/rcompat/tasks/86
- blueis that once flog updates, this build will fail
- bluethis is a correct observation by clankerhood
- bluetechnically it's the same problem here https://repopack.com/project/primate/tasks/238
- bluedo you need something like flog.run/install?version=XXX ?
- bluehold on
- bluetrying to understand
- phalethI cannot update flog#86
- bluesubmit it again
- blueI see, the trust me bro script supports FLOG_VERSION
- blueI missed that
- blueclanker apologised
- phalethheh
- phalethdamn primate#238 is already merged :D
- phalethwill create another one
- phalethbut I still cannot submit the change to flog#86 or rcompat#86? I don't know
- phalethrcompat#86
- bluercompat#86
- blue`rp task submit`
- blue`rp task submit .`
- bluedoesn't ework?
- phalethI mean not submit, but push commit to that task
- blueok let me fix repopack#740 first
- bluethat will improve your workflow
- blueyour latest note on repopack#740 will be accounted for in 740
- phalethwhy'd the clanker say it was wrong? on rcompat#86, it wasn't completely wrong
- phalethok, cool
- blueit wasn't wrong at all
- blueclanker hallucinated
- phalethyeah, also too bad it's spewing so much walls of text
- blueya
- phalethok, just make sure to merge https://repopack.com/project/primate/tasks/239 before new flog release
- blueflog 0.1.2 coming
- phalethI think once the branch gets restacked or whatever is the term then the work is busted
- phalethI mean the local branch
- bluedone
- blueyes, restacked
- bluealso rp 0.1.4 is soon coming with the 740 changes
- phalethnice :)
- phalethdo you want me to create repopack task for args to be passable to container image builds?
- phaleth`rp app args`
- phaleththere is already `rp app env set <app> <key>`
- phalethI mean `rp app env set <app> <key> --value-stdin`
- phalethI've set flog version env var for primate https://paste.debian.net/plainh/7940c836 we will see if 0.1.2 will be used on next deployment
- blueyes phaleth
- bluecreate a task please
- phalethyou think env var will not be applied? should give that a try I think
- bluewhere is that env var coming from?
- phalethnot sure what you mean, I've set that env var
- phalethhoping it will be passed to the image build via the --build-arg flag or whatever the rest API of podman uses
- phalethbut maybe those env vars are just a runtime thing, no clue
- phalethalso arg is a better name for this kind of thing since it's called ARG in the Containerfile as well
- bluebut only jobs supported --build-arg, is my point
- blueok, will change to --arg
- blueoh I see, you just used envs for apps. yes, that's correct
- phalethok, so these env vars are used both at buildtime and runtime?
- phalethdon't you think there should be a different mechanism for build and runtime
- phaleth--build-arg is good, that's descriptive and matches podman
- phalethand I think env vars should only be used at runtime, but then how to pass secrets to build if build requires secrets
- phaleththose env vars are already write only
- blueapps and jobs are different
- blueso should we do --build-arg or --arg for jobs?
- phalethjob is always running during a container build right?
- bluejob runs in a containre, yes
- blueand it's never long-running
- phalethI mean, it's always running as `podman build` not as `podman run -rm`
- blueyes
- bluewell, it's building an image
- bluethen runs it once
- phalethhmm, that's weird, it should just use a stock image and run things in a container spawned from that stock image
- phalethand then --arg would be appropriate
- phalethas runtime arg
- phalethI think `podman run -rm` should be the way, then the script the job runs can be just an sh script
- phalethactually can't remember if the flag to delete the container after it's done is `-rm`, but there is such flag
- phaleththat way we will not get a ton of podman build layers cached on the server
- bluephaleth: https://dpaste.com/HT5BZDQVS
- bluemaybe you can create a task for this?
- bluethen we can also decide if we use --build-arg or --arg flags.
- blueand also whether we rename `rp job args ...` to `rp job build-args ...`
- phalethok, so one task for jobs and another for app deployments
- blueyes
- phalethbut what I don't know is how env vars are used
- bluehold on, let me clarify then
- blueApps: rp app env set stores a write-only value. You bind its key to an App unit, and Repopack injects it when the container runs, not while its image builds. “Write-only” means the value cannot be read back through Repopack; it does not make it a safe build secret.
- phaleth`rp job args` will stay as is
- blueenv -> runtime
- phalethah, ok, that's right
- blueJobs: Today, rp job run --build-arg NAME=VALUE supplies a non-secret Containerfile build argument. It does not become a runtime env var or script argument. Image-mode Jobs currently have no equivalent per-Run runtime input mechanism.
- phalethI thought env is runtime thing
- blueit is
- blueSo these are separate concepts. If we add stock-image Jobs that run repository scripts, we can design runtime arguments for those Jobs—and decide their CLI name then. Build-time secrets would need their own safe mechanism.
- phalethok, and how to distinguish? --build-arg --build-arg-secret ?
- phalethpodman build also accepts ENV, that could be always write only
- blueyeah, we should create the two tasks and discuss there what's needed
- phalethactually no, podman build does not accept ENV
- bluefor jobs I haven't needed secrets yet
- bluebut it could be a use case
- phalethENV variables are embedded in the image metadata and visible to anyone who can inspect
- blueya
- phalethwell, how does for example the migration script primate generates work then?
- phalethit bakes in secrets that means secrets end up in image layer
- phalethfor us that is fine, but outside user would not want us have their secrets
- phalethNever use ENV for secrets.
- phalethduring image build that is
- blue"That script can be in the image without baking in the credential. Repopack’s App env bindings are injected at container runtime, not image build time. If Primate’s generated script actually writes a database password or URL literally into the script or image, that’s a real issue to inspect"
- phalethyeah, it has no clue obviously
- blueI feel like we're talking about a few different things at once
- phalethit just clankered a security problem
- phalethyeah, I know, three different things
- blueapps have envs, those are secrets
- bluethose are write-only; you cannot read htem again over the cli
- bluethey're also encrypted
- blue`rp app env`
- phalethyeah, that's understood
- blueok, there we don't need changes, right?
- phalethright, it's just using podman run -e under the hood
- phalethor the related podman REST API
- blueyes
- blueso that's ok. what's next?
- phalethlets just go back to jobs for a moment
- blueok
- phalethright now they are running within podman image build mostly
- phalethonly after that's over artifacts are somehow extracted
- phalethjobs have dependencies, for those it'd be nice if the user could say I wanna cache that step cause it's expensive and you guys charge me for job time
- phalethbut then the artifact production itself should not be cached cause it also requires the source code as second input
- phalethbuild-args that are not secrets might be fine unless those dependencies need to be fetched from some repository requiring auth
- phalethor the source code is not hosted on repopack at least partially
- phalethso it's good that there is cache currently but also bad cause we have to clear it and it's not controlled by the user what gets cached
- phalethand now that means simple sh script won't do, there have to be some stages to the job
- phalethalso I wanna bring my own stock image should be a usecase
- phalethalso how do we isolate builds, I think runsc can be used as runtime for containers as well as runtime for podman builds, but I don't really remember testing that after bugs got fixed in podman 6
- phalethalso the default stock image should just be alpine, not negotiable, if clanker can solve that one issue then lets bother it with apps
- phalethI think clanker has no chance there :)
- phalethalso you may say that runsc will be slow, for us we should still have option to use crun
- phalethcouple weeks ago I was thinking of documenting how to use an ephemeral builder in a separate disposable VPS, but if runsc is an option for builds
- blueok
- bluelet me review that
- phalethone sec
- phalethI have this in my notes https://paste.debian.net/plainh/217b1474
- phalethbut that's from the time when podman 6 wasn't a thing
- phaleththat means the stock image should be enforced and jobs should run at container runtime
- phaleththe caveat is when for example rp cli is built on alpine the cross-compilation requires cgo, on debian golang can cross-compile fine
- phalethso maybe there should be a limited choice of stock images for jobs
- bluetask incoming
- bluehttps://repopack.com/project/repopack/tasks/743
- phalethnice, clanker is gonna invent new scripting language to let people identify caches
- phalethit's prolly gonna argue that podman is not the right thing to use for this kind of problem
- blueit's all complexity, why do we need this
- blueit's currently working well, no?
- phalethcaching is hard, but we need security
- phalethand if people are running long running jobs and cannot optimize via caching then that's a problem
- phalethbut currently we don't need those two, sure
- bluepeople on free plans are gonna pretty limited anyway
- blueso for now we leave it as `rp job args` but `rp job run --build-arg`, yes?
- phalethwell, just consider at least moving from build time to runtime and take sh script as input
- bluemove what from build time to runtime?
- phaleth`rp job args` but `rp job run --arg ...`
- blueso you wanna change from --build-arg to --arg, ya?
- bluethat's ok for a small change for now
- phalethwhatever is currently defined in Containerfile should be defined in sh sript and then the container that runs the sh script can be executed using runsc to improve security
- phalethand there should be two stock images available alpine and debian
- blueI'm not sure I understand. what change do we want for now?
- phalethlet me give you an example
- blueok
- phalethhere you can see a Containerfile defining all the heavy lifting https://repopack.com/project/repopack/jobs/1?run=335
- phalethinstead there should just be a choice of alpine or debian
- bluebut plain alpine or debian doesn't contain go
- phaleththen all that heavy lifting should be executed via user defined sh script using `podman run -rm --runtime=runsc ...` (flags might be incorrect) behind the scenes
- phalethwell, you can make go images available if you want
- phaleththe point is the list is limited to trusted images
- phalethand so for us the --runtime or whatever is the correct flag anyway should be chooseable to crun
- bluebut then we need to maintain an eternally long list of trusted images
- phalethyeah, and it's easy to install golang
- phalethRUN wget -c -O golang.tar.gz https://go.dev/dl/go${GO_VER}.linux-amd64.tar.gz && \
- phaleth tar -C /usr/local -xzf golang.tar.gz
- phalethENV PATH="/usr/local/go/bin:${PATH}"
- phalethcompared to that node is pain in the butt to install in image build :)
- bluebut this is the approahc you should proposed replacing. it requires the ability to control the containerfile
- bluehold on
- phalethyeah, sorry, I mean they should do that in the sh script
- phalethbut you know if podman build accepts the runtime and does not fail then Containerfiles can still be used and so the layer caching mechanism of the podman build as well
- blueI don't know if I want to maintain trusted images, however I have another idea
- phalethyeah, I also think letting people use Containerfiles is great idea
- bluerp image create go-toolchain --file ci/Containerfile.tools
- phalethso that means we will need an ephemeral builder
- bluerp image build go-toolchain
- bluerp job create cli-check --image go-toolchain@<version> --script ci/check.sh
- bluerp job run <job-number> --source <full-sha> --attach
- bluethat solves the caching issue, right?
- blueusers can create their own base images
- blueand then reuse them in a project
- phalethyeah, just not sure how the last two calls relate to each other
- phalethbut makes sense to have four steps
- bluethe first one defines a reusable job
- bluethe second starts a run against a git sha
- phalethok, so rp job create will return the job-number
- phalethrp job create runner then?
- phalethand rp job run --runner <number>
- bluerp job create <job-name> --image <image-name> --script <entry-script>
- bluerp job run <job-number> --source <sha> --attach
- bluethat's what I propose. right now create works differently
- bluerp job create release '{"source":"refs/heads/master","execution":{"mode":"containerfile","containerfile":"Containerfile.release","context":"."},"artifact_paths":["/release"]}'
- phalethrp job run <job-name> --source <sha> --attach
- phaleththen it's good
- blueI think run suppotrs both number and name
- phalethyeah, at least that sounds doable
- blueok
- phalethwill prolly be hard for people to realize they shouldn't do everything at image build time, but that's a different problem
- phalethsome will prolly just do two stage builds if <image-name> is available via FROM call in Containerfile, which is at least better
- phalethcause who can be bothered with an sh script
- blueya
- phaleththat means it boils down to having a container registry
- phalethwhich is also what I thought about
- blueimage registry? ya
- phaleththis explains how to setup registry in a container https://oneuptime.com/blog/post/2026-02-08-how-to-set-up-docker-registry-with-basic-auth-and-htpasswd/view
- phalethessentially it's just: `podman run -d -p 5000:5000 --name cr registry:3`
- phalethand also volume flags
- bluewhat do we need it for?
- bluewe can just keep images locally for now, no?
- phalethso we can store custom images
- phalethlocally stored images is not a good idea, actually I tend to clean them up alot cause of all these security issues that have been reported
- phalethand it's difficult to distinguish between what is used/valid and what is just already obsolete when it's all on a single pile
- blueya
- phalethalso the registry allows accounts to be used, not saying namespacing is not possible in image naming, but still
- blueya
- phalethrepopack could also manage the images by itself and as written in repopack#392 it should anyway
- bluephaleth: https://repopack.com/project/repopack/tasks/743
- bluecan you provide input on this
- phalethyeah, sure
- bluethanks phaleth
- phalethno problem, added some comments that give reasons why to do all that
- bluealright
- phalethwell, wish I could edit comments, but whatever, clanker might understand
- bluejust post a new coment
- phalethyeah
- phalethhope that makes sense, after jobs are implemented then apps can also use the same approach
- phaleththis way we get security, cache and also the user can choose what to cache such that the cache isn't lost in case repopack stays on the same machine
- bluenice
- blueya, makes sense
- phalethargs can be moved from underneath `rp job` later
- phalethenv can be moved from underneath wherever it is later
- bluemoved where?
- phalethrp app env
- phalethnot sure, env is now app specific and args is job specific
- phalethand both jobs and apps should be able to use args and env
- phalethto project maybe?
- phalethor just have both in two places rp job and rp apps in the CLI cause of multiple jobs and apps having inputs of same name
- blueya maybe
- phalethor have them in their own space in the cli, but require job or app as input
- blueI'd be wary of keeping general secrets per project and not scoped to app
- phalethyeah, true
- phalethalso there are now releases which is like a third category I guess
- blueyes