Noissue - Consider Mercurial repository as absent without the .hg/hgrc file

Noissue - Consider Mercurial repository as absent without the .hg/hgrc file

According to the man page of hg(1):

The  location  of the source is added to the new repository's .hg/hgrc file, as the default to be used for future pulls.

So even if the clone goes wrong, the cronjob would make sure to get the latests changes, and the next provisioning would clone the repo in case it failed the first time.

[mathias, 2017-05-05 18:29:18]

https://codereview.adblockplus.org/29430622/diff/29430623/modules/web/manifes...
File modules/web/manifests/server.pp (right):

https://codereview.adblockplus.org/29430622/diff/29430623/modules/web/manifes...
modules/web/manifests/server.pp:105: onlyif => "test ! -e /opt/cms/.hg/hgrc",
You sure this works if the directory previously exists after i.e. an interrupted
clone? Doesn't Mercurial complain about not being able to clone into an existing
non-empty directory? And Please just use attribute creates instead of attribute
onlyif.

[f.lopez, 2017-05-05 19:08:54]

https://codereview.adblockplus.org/29430622/diff/29430623/modules/web/manifes...
File modules/web/manifests/server.pp (right):

https://codereview.adblockplus.org/29430622/diff/29430623/modules/web/manifes...
modules/web/manifests/server.pp:105: onlyif => "test ! -e /opt/cms/.hg/hgrc",
On 2017/05/05 18:29:18, mathias wrote:
> You sure this works if the directory previously exists after i.e. an
interrupted
> clone? Doesn't Mercurial complain about not being able to clone into an
existing
> non-empty directory? And Please just use attribute creates instead of
attribute
> onlyif.

Yeah, the problem I found was that when it timed out the directory was created
but it was empty, so there was not another attempt, if the .hg folder is
created, the hgrc is created as well with the source of the repository, which
leads to a pull instead of aclone, even if the clone was corrupted, the pull
should fix that the next time, which can be a second provisioning

[f.lopez, 2017-05-05 20:10:08]

On 2017/05/05 20:07:13, f.lopez wrote:

There is a related issue, the site is never generated within the provisioning,
the site is generated after the cronjob executes the python script.

[mathias, 2017-05-05 20:13:07]

On 2017/05/05 20:10:08, f.lopez wrote:
> There is a related issue, the site is never generated within the provisioning,
> the site is generated after the cronjob executes the python script.

How is that an issue? And how is it related to this review?

Also, please come up with a better commit message.

[f.lopez, 2017-05-05 20:14:20]

On 2017/05/05 20:13:07, mathias wrote:
> On 2017/05/05 20:10:08, f.lopez wrote:
> > There is a related issue, the site is never generated within the
provisioning,
> > the site is generated after the cronjob executes the python script.
> 
> How is that an issue? And how is it related to this review?
Fair enough.
> 
> Also, please come up with a better commit message.

[f.lopez, 2017-05-05 20:18:26]

> Also, please come up with a better commit message.

"Ensure that repository is initialized" ?

Cause even if the clone failed for whatever reason, if the repository was
correctly initialized the cronjob will take care of getting the latest changes

[mathias, 2017-05-06 16:09:05]

LGTM.