@forgejo @gitea what is the preferred API to fetch unstarted actions?

[dcz@fosstodon.org]

@forgejo @gitea what is the preferred API to fetch unstarted actions?

I want to wake my #CI computer when a job is pending, but I'm not sure which call I should use.

I found the protobuf API, but it's not documented enough that I know how to use it E.g. is fetching the same as accepting? What are the URLs?

actions-proto-def/messages.proto at main

actions-proto-def - Protocol Buffer schema for Gitea Actions.

Gitea: Git with a cup of tea (gitea.com)

#forgejo #ForgejoActions #gitea #GiteaActions

[earlwarren@mastodon.online]

@dcz @forgejo this API is not meant to be used in this way. You could do web scrapping on the UI page that displays the pending jobs on a given repository. Not pretty but that would work.

[algernon@trunk.mad-scientist.club]

@earlwarren @dcz @forgejo There's actually a way to do something like this via the API, without scraping the UI! I'm using it in the weekly-cherry-script script.

The flow is something like this:

• Figure out the commit SHA of the branch you want to check unstarted jobs for (eg, /api/v1/repos/{owner}/{repo}/commits?limit=1, and look for the sha key of the single returned object)
• You can then list the statuses associated with the commit via the /api/v1/repos/{owner}/{repo}/commits/{commit_id}/statuses endpoint
• Merge the entries by target_url (sorted by id)
• If there's any in the remaining set with a pending status, wake the CI computer.

The merging part is important, because the statuses endpoint will return all states: for a successful job, it will have both a pending and a success entry.

You may be interested in the weekly-cherry-pick script's api.sh, and session/cmd/ci.sh parts, these two showcase how to use the API, merge stuff, and a few other things.

Not the most convenient, but doable, and in my opinion, more reliable than scraping the web UI.

[dcz@fosstodon.org]

@algernon @earlwarren @forgejo Omg, making this work for merge request sounds like an absolute nightmare.

[algernon@trunk.mad-scientist.club]

@dcz @earlwarren @forgejo Why would it be? You can grab the SHA of the head of a merge requests via the API (and you can also get a list of merge requests via the API), and the rest is "just" an API call and some jq magic. It's not simple, but I wouldn't call it a nightmare either.

But yeah, if you don't want the script to iterate over a lot of stuff every time it is triggered, it would need to keep some state, and then that would become nightmareish quickly.

Perhaps a better solution would be to enable metrics, and monitor the
actions_ready_job queue, and start up the CI machine if the number of items in queue is non-zero.

[dcz@fosstodon.org]

@algernon @earlwarren @forgejo The brittleness would be in having to add projects manually.

Also in a simple monitoring of jobs without metadata like the type or name of runner. A job without a suitable runner would keep waking them all.

I think the only reasonable way to deal with this runner problem is to solve it via the runner API.

[algernon@trunk.mad-scientist.club]

@dcz @earlwarren @forgejo Oh, I see. Yeah, if you have multiple runners and you don't want to wake them all every time, that does complicate things considerably.

So in the end, yes, this is likely best solved at a runner API level indeed.

[dcz@fosstodon.org]

@algernon @earlwarren @forgejo I don't really have multiple ones and only care about one project, but sheesh! Things should be solved in the right place rather thn hacked around.

I'll reverse-engineer this open-source project if I have to.

@pintoch wanna help :P?

[pintoch@mamot.fr]

@dcz @algernon @earlwarren @forgejo it's an interesting problem - I thought about that to provide a MacOS CI with a machine I have lying around. Maybe it's worth trying to specify what the right API for this use case should look like, and then just implement it in Forgejo?

[algernon@trunk.mad-scientist.club]

@pintoch @dcz @earlwarren @forgejo A while ago, I contemplated using microVMs, started on-demand. A somewhat similar scenario, I think. At the time, the easiest solution seemed to be to have an always-on runner, which can spin up VMs / start other ci machines, and then act as a proxy.

Or, perhaps easier: a runner that takes a peek at jobs, but doesn't accept them, and starts the real runner as a side-effect. So there would be two runners registered, a real one, and a fake to wake the other.

I never got past the idea stage, though.