magit
Support for CI status
Most forges support some sort of build/testing status from the various CI solutions out there (Gitlab's own, Travis CI, CircleCI, ...?) -- this information should have a home in Forge.
vermiculus/magithub#399
I am unsure how this should be done. Really, it's a property of a commit, but there is no current structure for these objects. We could get around that by having a map of commit identifiers to status objects in a forge-repository.
I seem to remember talking about this before, but I don't recall where ☹️ No implementation specifics -- just more Forge philosophy that it's not necessarily opposed to storing information available from only one Forge.
Also, have you considered moving ghub-get-repository into Forge? It does make it inconvenient to add information like this. AFAICT, I'll have to submit a PR to add status information to the relevant queries.
While I would like CI support too, I think this is one of those features we should delay until have settled down more. It's a whole new cans of worms.
Also, have you considered moving
ghub-get-repositoryinto Forge?
Did you mean "forge-get-repository into Ghub"?
I did mean from ghub -> forge, but I botched the variable name; my bad.
Referring to constant ghub-fetch-repository:
https://github.com/magit/ghub/blob/f1b8aebf99a7de298de6333a82c9b714609f2e99/ghub-graphql.el#L73
Currently I use something like this to cache my PRs into Emacs every twenty seconds or so.
;; load ghubp functions
(use-package magithub
:straight t
:init
(require 'ghub+))
(defun github-get-prs ()
(let ((repo (ghub-get "<my-repository>"))
(user "<my-username>"))
(defun ref-to-status (ref)
(list ref
(with-timeout (3 "failure")
(cdr (assoc 'state (ghubp-get-repos-owner-repo-commits-ref-status repo ref))))))
(mapcar
#'ref-to-status
(mapcar
(lambda (pr) (cdr (assoc 'ref (assoc 'head pr))))
(-filter
(lambda (pr) (s-equals-p user (cdr (assoc 'login (assoc 'user pr)))))
(ghubp-unpaginate (ghubp-get-repos-owner-repo-pulls repo)))))))
Then that gives me the status, which I can use to prioritize open PRs which have stopped blocking.
I'm hoping to one day replace the magithub dependency here.
Ah you're right! Not sure why that didn't work the first time I wrote that snippet. That saves me time in my use-package loads. Thank you.
I was just iterating over some code in emacs, using magit to push my code, then having to switch to my browser to go to my gitlab instance, to go to the CI pipelines page, then click on the job and watch the build output. I was having to do this over and over, when I thought... wouldn't it be nice if I could just push via magit, and a little minibuffer window would pop up in emacs with the build output of my gitlab CI job, updating in real-time?
Yes, that would be cool.
I know gitlab has an API that you can pull this from, so it would just need to connect all the pieces and refresh that until it finished.
👍
On Thu, Sep 26, 2019, 01:54 micah [email protected] wrote:
I was just iterating over some code in emacs, using magit to push my code, then having to switch to my browser to go to my gitlab instance, to go to the CI pipelines page, then click on the job and watch the build output. I was having to do this over and over, when I thought... wouldn't it be nice if I could just push via magit, and a little minibuffer window would pop up in emacs with the build output of my gitlab CI job, updating in real-time?
Yes, that would be cool.
I know gitlab has an API that you can pull this from, so it would just need to connect all the pieces and refresh that until it finished.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/magit/forge/issues/92?email_source=notifications&email_token=AABBX24LMUBEKONYPOQTUVDQLPT4FA5CNFSM4GSQWXI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7TVSFQ#issuecomment-535255318, or mute the thread https://github.com/notifications/unsubscribe-auth/AABBX2YR7WL576L5NUDYFUTQLPT4FANCNFSM4GSQWXIQ .
Any news ? This would be such a great feature to have ! It's the last thing preventing me from living in Emacs :)
I would be interested in implementing this. However, I have never interacted with the forge codebase before. Could anybody familiar give me a few pointers about where I should look to get started?
@sgpthomas I think it is probably going to be pretty hard to implement this for someone who is not familiar with the code base yet. That doesn't mean you should not attempt it, but that you should be prepared to do a lot of reading and experimenting. You'll also find things that are a bit weird; I would like to improve those, but time...
Begin by implementing this just for pull-requests, leaving "tip of branch" aside for now. Forge already stores information about pull-requests in its database, not so for branches.
So for pull-requests you only have to figure out how to add a new field/slot/column and update it. For branches you would have to figure out much more about my adhoc, leaky orm thingy (which I wrote when I first learned about (the very basics of) databases). To learn how to do that, trace (l t in magit) something that changes when a new slot is added, e.g., forge--db-table-schemata. Look for commits that add a single column and look at those to learn what other places have to be adjusted.
Once the data is available locally, you have to figure how to display it, but I suspect that will be more fun.
It appears that I will have to make changes to the ghub graph ql queries in order to get information about check suites and workflows. I can of course make this into a separate query and use the ghub-graphql function, but then this adds an additional query to the API. I was wondering if there is a particular reason that these queries live in ghub and not forge.
In the meantime I will continue to mock this up by using an additional query.