- Jan 24, 2020
-
-
Georges Racinet authored
-
- Jan 23, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
Since this serves to know the image/tag of the base image this also prevents --pushi to push all tags.
-
- Jan 16, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jan 15, 2020
-
-
Georges Racinet authored
Went through the full hg log, it should be transparent to Heptapod, almost entirely about things that aren't relevant to us for the time being. So let's have it for 0.8.0
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
But that wouldn't work if trying to use a topic.
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jan 14, 2020
-
-
Georges Racinet authored
This file is the one whose changes trigger the run of database migrations at startup. So, for heptapod#159 we need it to change according to Heptapod revisions, not the mostly fixed upstream GitLab revision
-
- Jan 08, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jan 07, 2020
-
-
Georges Racinet authored
-
- Jan 08, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
Since the migration for 0.7.0, `hgrc.local` and subgroup hgrc files have had the wrong root:root ownership. The migration for 0.8.0rc2 made that obvious by making `hgrc.local` the repo `hgrc`.
-
- Jan 07, 2020
-
-
Georges Racinet authored
This blocks the startup in our first attempt for a 0.8.0rc2 image
-
Georges Racinet authored
-
Georges Racinet authored
We don't need it, the various components (Rails app, hgserve, Heptapod Shell) take care of it with HGRCPATH. That means in repos that we don't need the `hgrc.local` any more and can simply make it the `hgrc` again. Now repos hgrcs and the global /etc/gitlab/heptapod.hgrc are under full control of the local admin, with no trap, and there's no adherence to the fact that this is a Docker instance: it could be converted later to a source or Omnibus install
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
This is part of heptapod#144: we don't need that key any more and we don't want it around now that there is a regular use of SSH in Heptapod. This is placed in the startup sequence at the moment where we used to create the key.
-
- Jan 06, 2020
-
-
Georges Racinet authored
this /opt/gitlab/etc/docker.hgrc is among the ones loaded by default by the Rails app, hence it'll work on Docker installs because we don't have Mercurial configuration for the Rails app at all. The content of the file is what used to be actually meant for Docker installs in the previous 'repos.hgrc' in the Rails app: repositories and gitlab-shell location. The next step would be to make Ommibus/Chef rules for this and just use it.
-
- Jan 02, 2020
-
-
Georges Racinet authored
and that means that our small patch is no longer necessary, the fix being included upstream
-
- Dec 26, 2019
-
-
Georges Racinet authored
-
- Dec 25, 2019
-
-
Georges Racinet authored
-
- Dec 22, 2019
-
-
Georges Racinet authored
In the next version of Heptapod, we'll fire the appropriate pre-receive hook directly from Mercurial, meaning that we don't need to go over SSH to validate user and project.
-
- Dec 19, 2019
-
-
Georges Racinet authored
The default 2022 port on host is the one expected in `heptapod-tests`
-
- Dec 23, 2019
-
-
Georges Racinet authored
-
Georges Racinet authored
This has been done in the `heptapod-0-7` branch, where it mattered most at the time.
-
- Dec 19, 2019
-
-
Georges Racinet authored
with Heptapod development being more and more branching, it makes sense for the default setup to avoid running 0.6 over volumes meant for 0.7 etc.
-
- Dec 22, 2019
-
-
Georges Racinet authored
At the time of this writing, `py-heptapod` and `hg-git` don't have an `heptapod-0-8` branch, but they will before 0.8.0rc1
-