We have finished the SCM source type implementation. You can read more in this blog post: https://clime.github.io/2017/10/24/COPR-SCM.html
Thank you for the feedback! clime On Wed, Sep 27, 2017 at 10:28 PM, Michal Novotny <cl...@redhat.com> wrote: > Hello, > > On Tue, Sep 5, 2017 at 5:50 PM, Petr Stodulka <pstod...@redhat.com> wrote: > >> >> >> On 4.9.2017 19:27, Michal Novotny wrote: >> > I might contact you for more information, but alright, if you feel the >> custom script is more convenient, >> > then I am all for it. But first, I would like to make a proposal of >> each option (with screenshots and >> > just complete feature request description) so that users can clearly >> see the options and pick what >> > they like the best. We can work with Pavel on it. >> > >> > If you agree, I would post the two proposals here before actual >> implementation. >> > >> >> Yes, it would be fine see concrete proposals to discuss it before >> implementation. Thanks. >> > > in the end, we decided, we will probably try out both ways. I will likely > implement the 'make srpm' > command in addition to 'tito', 'tito --test', 'rpkg' options in the SCM > tab and Pavel will make new > source type called 'Custom' (or something similar) where user can script > out the way how sources > for a subsequent srpm build are going to be fetched. This script will be > stored in DB and will > launched in a chroot initialized by a set of predefined buildroot packages > (i.e. fedpkg, wget,). Both > solutions will be fairly equivalent, except in the first case the script > will be stored in a Git repository, > whereas in the second, it will be stored in the COPR database. The latter > will likely offer more > more freedom in where to fetch sources from (i.e. launchpad.net or CPAN) > whereas the former > will be focused mainly on Git and SVN (likely) sources. > > Consider this still to be in a proposal state. We will see how well the > actual implementation goes. > > >> >> P. >> >> >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> >> >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
