Hello folks,
codebase will be now hosted on pagure.io (https://pagure.io/copr/copr). We would like to start working on this platform. Not that Github is bad but I think that pagure.io will be good place as well.
COPR team
Shouldn't be this line updated?
https://pagure.io/copr/copr/blob/master/f/README.md?text=True#_3
And the fedorahosted should be update as well IMO.
Vít
Dne 21.10.2016 v 13:00 Michal Novotny napsal(a):
Hello folks,
codebase will be now hosted on pagure.io http://pagure.io (https://pagure.io/copr/copr). We would like to start working on this platform. Not that Github is bad but I think that pagure.io http://pagure.io will be good place as well.
COPR team
copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
Hello Vit,
do you mean line 3 in the README.md? ("Project Page") That is should be ok. It says
https://fedorahosted.org/copr/
I updated repo link in that page. Thanks!
On Fri, Oct 21, 2016 at 1:19 PM, Vít Ondruch vondruch@redhat.com wrote:
Shouldn't be this line updated?
https://pagure.io/copr/copr/blob/master/f/README.md?text=True#_3
And the fedorahosted should be update as well IMO.
Vít
Dne 21.10.2016 v 13:00 Michal Novotny napsal(a):
Hello folks,
codebase will be now hosted on pagure.io (https://pagure.io/copr/copr). We would like to start working on this platform. Not that Github is bad but I think that pagure.io will be good place as well.
COPR team
copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
On Friday, October 21, 2016 1:00:05 PM CEST Michal Novotny wrote:
Hello folks,
codebase will be now hosted on pagure.io (https://pagure.io/copr/copr). We would like to start working on this platform. Not that Github is bad but I think that pagure.io will be good place as well.
COPR team
Good argument would be also that we want to eat our own (open source && fedora) dog. +1.
Can you please copy the issue database and pull request database (even the closed items), so that the git-log points to correct issues within pagure?
Also, could you please reflect the FAS 'gitcopr' commit group?
Thanks, Pavel
Dne 21.10.2016 v 13:00 Michal Novotny napsal(a):
codebase will be now hosted on pagure.io http://pagure.io (https://pagure.io/copr/copr). We would like to start working on this platform. Not that Github is bad but I think that pagure.io http://pagure.io will be good place as well.
Sorry to say that, but this changed was not discussed neither here nor in the team. So I have to reject this. The upstream will stay on GitHub for now. It may change in future, but not now. Please continue sending PRs to GitHub.
After some discussion, the main argument against move to pagure is that commit-induced auto-rebuilding of COPR packages will be disabled by this.
I am working on alleviating this issue. Hopefully, it will go well.
clime
On Mon, Oct 24, 2016 at 11:32 AM, Miroslav Suchý msuchy@redhat.com wrote:
Dne 21.10.2016 v 13:00 Michal Novotny napsal(a):
codebase will be now hosted on pagure.io http://pagure.io (
https://pagure.io/copr/copr). We would like to start
working on this platform. Not that Github is bad but I think that
pagure.io http://pagure.io will be good place as well.
Sorry to say that, but this changed was not discussed neither here nor in the team. So I have to reject this. The upstream will stay on GitHub for now. It may change in future, but not now. Please continue sending PRs to GitHub.
-- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
On Thu, Oct 27, 2016 at 07:22:02PM +0200, Michal Novotny wrote:
After some discussion, the main argument against move to pagure is that commit-induced auto-rebuilding of COPR packages will be disabled by this.
I am working on alleviating this issue. Hopefully, it will go well.
Pagure supports web-hook as well as fedmsg for notifying of an action. There is also of course the possibility to add COPR as some sort of CI service like we have for jenkins but that would be a little more work on pagure itself.
Let me know if I can help with something!
Pierre
On Thu, Oct 27, 2016 at 7:56 PM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
Pagure supports web-hook as well as fedmsg for notifying of an action. There is also of course the possibility to add COPR as some sort of CI service like we have for jenkins but that would be a little more work on pagure itself.
Let me know if I can help with something!
Thank you. I have already implemented some basic fedmsg listener that launches builds on pagure.git.receive message. It works but it would be nice to extend the message with the information about modified paths in the repository so that only the corresponding sub-package(s) are rebuilt (in COPR repo, there are 10 subpackages at least, which is quite a lot of building when only one of them has been actually updated). I will gladly send a PR for this unless there happens to be some better way.
Pierre
copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
On Mon, Oct 31, 2016 at 08:30:28AM +0100, Michal Novotny wrote:
On Thu, Oct 27, 2016 at 7:56 PM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
Pagure supports web-hook as well as fedmsg for notifying of an action. There is also of course the possibility to add COPR as some sort of CI service like we have for jenkins but that would be a little more work on pagure itself. Let me know if I can help with something!Thank you. I have already implemented some basic fedmsg listener that launches builds on pagure.git.receive message. It works but it would be nice to extend the message with the information about modified paths in the repository so that only the corresponding sub-package(s) are rebuilt (in COPR repo, there are 10 subpackages at least, which is quite a lot of building when only one of them has been actually updated). I will gladly send a PR for this unless there happens to be some better way.
We used to send more info but had to trim it down due to some massive commits that were basically breaking datagrepper (OutOfMemory), but if there is an use-case I'm fine with expending the amount of information sent. Worst case, do the computation client-side, listen to fedmsg, get the start and stop commits and see which files were touched in between.
Pierre
On Mon, Oct 31, 2016 at 8:40 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
We used to send more info but had to trim it down due to some massive commits that were basically breaking datagrepper (OutOfMemory), but if there is an use-case I'm fine with expending the amount of information sent. Worst case, do the computation client-side, listen to fedmsg, get the start and stop commits and see which files were touched in between.
In the simplest case, we would need directory/file names of level 1 where there was a change. That's perhaps a little too specific though. I would still very much welcome this or overall list of modified paths. Not saying, I can't put together some really messy code to get that information from the patches :).
Pierre
copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
On Mon, Oct 31, 2016 at 11:59:47AM +0100, Michal Novotny wrote:
On Mon, Oct 31, 2016 at 8:40 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
We used to send more info but had to trim it down due to some massive commits that were basically breaking datagrepper (OutOfMemory), but if there is an use-case I'm fine with expending the amount of information sent. Worst case, do the computation client-side, listen to fedmsg, get the start and stop commits and see which files were touched in between.In the simplest case, we would need directory/file names of level 1 where there was a change. That's perhaps a little too specific though. I would still very much welcome this or overall list of modified paths. Not saying, I can't put together some really messy code to get that information from the patches :).
If you're not against shelling out commands, you could try:
Get the list of commits: git rev-list old_commit..new_commit
Get the list of file changed in a specific commit: git diff-tree --no-commit-id --name-only -r <hash of the commit>
Pierre
On Mon, Oct 31, 2016 at 12:05 PM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Mon, Oct 31, 2016 at 11:59:47AM +0100, Michal Novotny wrote:
On Mon, Oct 31, 2016 at 8:40 AM, Pierre-Yves Chibon <
pingou@pingoured.fr>
wrote:
We used to send more info but had to trim it down due to somemassive
commits that were basically breaking datagrepper (OutOfMemory), but ifthere is
an use-case I'm fine with expending the amount of information sent. Worst case, do the computation client-side, listen to fedmsg, getthe
start and stop commits and see which files were touched in between.In the simplest case, we would need directory/file names of level 1
where
there was a change. That's perhaps a little too specific though. I would still
very
much welcome this or overall list of modified paths. Not saying, I can't put
together
some really messy code to get that information from the patches :).
If you're not against shelling out commands, you could try:
Get the list of commits: git rev-list old_commit..new_commit
Get the list of file changed in a specific commit: git diff-tree --no-commit-id --name-only -r <hash of the commit>
The problem is that we don't have the repository cloned at the point the fedmsg is received. And to always clone the repo to run the commands would be a bit troublesome.
Pierre _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-leave@lists.fedorahosted.org
Dne 31.10.2016 v 13:22 Michal Novotny napsal(a):
> In the simplest case, we would need directory/file names of level 1 where > there was > a change. That's perhaps a little too specific though. I would still very > much welcome > this or overall list of modified paths. Not saying, I can't put together > some really messy > code to get that information from the patches :).
Not exactly true. Yes Copr git repository is quite flat and we have everything just in one level. But there are projects, which have much deeper structure (e.g. Spacewalk).
If you're not against shelling out commands, you could try: Get the list of commits: git rev-list old_commit..new_commit Get the list of file changed in a specific commit: git diff-tree --no-commit-id --name-only -r <hash of the commit>The problem is that we don't have the repository cloned at the point the fedmsg is received. And to always clone the repo to run the commands would be a bit troublesome.
Yes, the repository can be hundreds MB large. And we cannot keep it and cache it. So checking it out after every commit just to determine the information is overkill.
Dne 27.10.2016 v 19:56 Pierre-Yves Chibon napsal(a):
Pagure supports web-hook
I still did not seen any documentation about it. And my common sense is failing. I really do not know how to use those web-hooks.
On Tue, Nov 01, 2016 at 09:52:43AM +0100, Miroslav Suchý wrote:
Dne 27.10.2016 v 19:56 Pierre-Yves Chibon napsal(a):
Pagure supports web-hook
I still did not seen any documentation about it. And my common sense is failing. I really do not know how to use those web-hooks.
Well there is https://docs.pagure.org/pagure/usage/using_webhooks.html no 'did not seen any documentation about it' seems either a little strong, that you didn't look very far or that for some reasons the doc is unused.
The documentation can however always be improved, but, and I'm sure you will agree, it's kinda hard when you develop something to know what users will struggle with. So I'm up for improving the docs if I'm told which aspects should be.
Pierre
Dne 1.11.2016 v 10:46 Pierre-Yves Chibon napsal(a):
Well there is https://docs.pagure.org/pagure/usage/using_webhooks.html no 'did not seen any documentation about it' seems either a little strong, that you didn't look very far or that for some reasons the doc is unused.
Nice. Thank you. So the problem was that I was unable to find it. The problem may be that google search "pagure webhook" does not find this page. It may be because you use "web-hook" instead of "webhook". I am not native speaker, but google fight suggest that "webhook" is the correct form.
The documentation can however always be improved, but, and I'm sure you will agree, it's kinda hard when you develop something to know what users will struggle with. So I'm up for improving the docs if I'm told which aspects should be.
Even with the documentation, I had hard time to find the setting. I had to use Ctrl+F.
There is a box about web-hook, but it contains just the private key. The actual webhook is buried in project options:
I would recommend you to: * Rename the box "Private web-hook key" to "Webhooks" * move "Activate Web-hooks :" to top of "Webhooks" box * Put in that "Webhook" box link to https://docs.pagure.org/pagure/usage/using_webhooks.html so developers can easily discover this page.
copr-devel@lists.fedorahosted.org
-
Michal Novotny -
Miroslav Suchý -
Pavel Raiskup -
Pierre-Yves Chibon -
Vít Ondruch