ve commit users, that locking feature would
have been useful if it can lock only 1 single branch, time to
stabilize it if need be.
But locking the entire repo is way too invasive and disruptive.
So I'd say drop the current repo wide locking feature unless it can
lock only 1 single or a list of b
il([rec.email], subject, email_txt_body,
> email_html_body, headers, author=created_by_obj)
>
> return notif
>
> If however, the entire notifications feature is found not useful by
> users, then we can get rid of it entirely.
>
> Thanks,
> Thomas
&
upstream so a dev checkout is essentially broken.
Is there a quick work-around for this now?
There a lfpull command added by largefiles. Can Kallithea call that
command after/before a regular pull to cache all the newer largefiles
from upstream?
Thanks,
--
Long Vu | Software Developer, Tools
Dominik
>
>
> ___
> kallithea-general mailing list
> kallithea-general@sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
--
Long Vu | Software Developer, Tools & Infrastructure | Inteler
plugin to automatically create jobs for
all repos and all branches in each repo, basically emulating the
Organization Folder support for Github and Bitbucket in Jenkins, but
for Kallithea and hgweb.
--
Long Vu | Software Developer, Tools & Infrastructure | Intelerad |
+1-514-931-6222 ext.
On Wed, Nov 15, 2017 at 12:04 PM, Dominik Ruf <dominik...@gmail.com> wrote:
>
>
> Long Vu <long...@intelerad.com> schrieb am Di., 14. Nov. 2017 um 23:33 Uhr:
>>
>> On Tue, Nov 14, 2017 at 4:55 PM, Dominik Ruf <dominik...@gmail.com> wrote:
>> >
>&
so the history of my repo is
> a bit ugly. Sorry.
Since that is your own host and you are the author of the "repository
settings (phases) v5 PR"
(https://bitbucket.org/conservancy/kallithea/pull-requests/343), why
don't you enable evolve on your own instance yourself to use named
br
hea/kallithea-domruf/raw/26ccf792b435/docker/docker-compose.yml
>
>
I tried that docker-compose.yml, everything just work ... so next step is
logging in ... what's the admin password? :D
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
This email or any attachments
/fail status back to
Kallithea to be displayed when someone is browsing the PR or the
commits.
Is this reverse way possible?
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
This email or any attachments may contain confidential or legally
privileged information intended
Kallithea is present in the section "Features" and "Version control systems".
But it is missing in the first section "General information" and "Popularity".
https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities
Is this intended?
--
for that, but first I'd like to ask, if we shouldn't remove
> some of the options.
> I feel like make-config should only generate setups, that are used by one of
> us and we therefore know are actually working.
>
Ah "auto generated certified setup" would be friendly and less er
New issue 288: Repo admin should be allowed to delete PR
https://bitbucket.org/conservancy/kallithea/issues/288/repo-admin-should-be-allowed-to-delete-pr
Long Vu:
Right now, only the PR owner see the "delete" button in the list of PR for a
given repo.
The repo admin should also h
hat was the conclusion of
> that?
>
> Thanks,
> Thomas
> ___
> kallithea-general mailing list
> kallithea-general@sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
On Wed, Jul 19, 2017 at 12:40 PM, Dominik Ruf <dominik...@gmail.com> wrote:
> Long Vu <long...@intelerad.com> schrieb am Di., 18. Juli 2017 um 22:41 Uhr:
>>
>> Hi,
>>
>> If we want to fire some automated tests upon PR creation/update is
>> there so
://kallithea.readthedocs.io/en/latest/api/api.html but they do not
do what I need.
Thanks.
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
This email or any attachments may contain confidential or legally
privileged information intended for the sole use of the addressees. Any
use
repo but each of us have our own
personal branch(es) (using Evolve). Then we create PR for the
different branches always from the same fork repo to the master repo.
Once the PR is accepted, we rebase the perso branch on the release
branch and the perso branch just disappear due to evolve.
on't know about closing, but I reckon you can always delete a PR via "My
> Pull Requests" list.
>
> On Jul 7, 2017 17:14, "Long Vu" <long...@intelerad.com> wrote:
>>
>> Hi,
>>
>> One of the user created a PR with a diff so gigantic (it was an
the PR (so
have to load the PR but that PR is crashing the browser).
Is there another way (maybe direct DB manipulation or another location
to access that delete button) to close the PR?
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
This email or any attachments may
kallithea-general mailing list
> kallithea-general@sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
This email or any attachments may contain confidential or legally
privil
THEA_PATH && \
>> +chown -R kallithea $KALLITHEA_PATH
>>
>> -apt-get purge --auto-remove -y python-dev && \
>> +RUN apt-get purge --auto-remove -y python-dev && \
>> apt-get autoremove && \
>> apt-get autoclean && \
>>
fi
>
> -# install dockerize
> -RUN cd $KALLITHEA_PATH && \
> -wget
> https://github.com/jwilder/dockerize/releases/download/v0.4.0/dockerize-linux-amd64-v0.4.0.tar.gz
> && \
> -tar -C /usr/local/bin -xzvf dockerize-linux-amd64-v0.4.0.tar.gz && \
&
PR before but due to my unfamiliarity with the
code, it's slow for me to incorporate review feedback (I have 1 PR
waiting for me to incorporate feedback ... since more than a year).
But I can volunteer to test.
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
T
with ability to automatically
turn on phase.publish=false and extensions.evolve.serveronly= will be
really useful.
Thanks,
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
This email or any attachments may contain confidential or legally
privileged information intended
context)
File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py",
line 450, in do_execute
cursor.execute(statement, parameters)
OperationalError: (sqlite3.OperationalError) no such table:
permissions [SQL: u'SELECT permissions.permission_id AS
permissions_permis
On Mon, Apr 10, 2017 at 10:26 PM, Mads Kiilerich <m...@kiilerich.com> wrote:
> On 04/11/2017 04:03 AM, Long Vu wrote:
>>
>> On Mon, Apr 10, 2017 at 5:03 PM, Mads Kiilerich <m...@kiilerich.com>
>> wrote:
>>>
>>> On 04/10/2017 05:05 PM, Vereten
?at=default=file-view-default
See discussion on
https://bitbucket.org/conservancy/kallithea/pull-requests/305/repository-settings-phases/diff
It was a smooth upgrade for me. As usual, always backup your config
and data before any upgrade, just in case.
--
Long Vu | Build Controller | Intelerad
and webserver should I use?"), a Docket image will often only be a
>> starting point. Actual documentation about pros and cons is much more
>> valuable.
>>
>> FWIW, at work we're currently experimenting with uWSGI in zerg mode
>> tightly coupled with syst
xisting docker images when upgrading celery and paster/gearbox
> ... and decided to create my own docker config that worked for that purpose.
> I could clean that up and contribute that too.)
>
> /Mads
>
> ___
> kallithea-general mailing
+++1 and volunteer to test it.
On Mar 23, 2017 18:53, "Dominik Ruf" wrote:
> Hi all,
>
> I've been using docker for a while now for my kallithea server and others
> have also mentioned that they are using docker.
> So what are the thoughts about creating an official docker
gure themselves and the admin is
out of the hook.
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
This email or any attachments may contain confidential or legally
privileged information intended for the sole use of the addressees. Any
use, redistribution, disclosure,
On Tue, Mar 21, 2017 at 6:34 PM, Sean Farley <s...@farley.io> wrote:
> Long Vu <long...@intelerad.com> writes:
>
>> Hi,
>>
>> I have 0.3.2.
>>
>> I've been doing this for each new repo creation, when needed, by
>> editing directly the .hg
all repos need publish = false.
Thanks.
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
This email or any attachments may contain confidential or legally
privileged information intended for the sole use of the addressees. Any
use, redistribution, disclosure
he users. I still have
to manually assign those users coming from LDAP to a local group?
--
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743
--
This email or any attachments may contain confidential or legally
privileged information intended for the sole use of the ad
33 matches
Mail list logo