Daniel Mohr (6b58df26) at 14 Nov 17:02
cf. #12
Daniel Mohr (6b58df26) at 14 Nov 16:27
moved pre-commit to an other stage tu run earlier
cf. #12
Daniel Mohr (fb47eebf) at 14 Nov 10:58
adapted regarding moving from gitlab.hzdr.de to codebase.helmholtz....
... and 1 more commit
@Daniel.Mohr @a.pirogov How complicated would it be to enable your pipeline to access files from other GitLab projects (in the same subgroup)?
I am just asking because at the moment the TF Survey has two projects - one for the analysis and one for the report. At the moment we are still working on the anaylsis and updating our outputs, while we simultaneously write the report. So it would be great to access the recent version when the pipeline in the document repo runs.
If it is too complicated, do you have an idea how we could easiliy do a workaround?
We could enhance the workflow to enable (at least optional) to store the job artifacts in a branch.
In this way the repository can be archived/cloned and the full information is still available.
Note: I do not know a way to copy the job artifact from one gitlab instance to an other (possible new) one.
yep, works as Daniel explained. =)) Thread can be closed.
Thanks for the quick answer. If I get stuck while implementing your suggestion I get back to you.
I don't know about the subgroups making a difference, would also not think so except for default user permissions it shouldn't matter.
Apart from that I guess I have nothing to add to what Daniel suggested :)
It's not too complicated. It's just the way gitlab works and gives access to data stored somewhere.
So, in the pipeline the process needs access to a not public repository. Therefore the process needs some mechanism for authentication. I don't think that the same subgroup makes a difference (@a.pirogov ?); maybe you could store some secrets on group level instead of repo level -- but this does not help.
Our 'environment' (Pandoc Latex Build, hmc-document-template, ...) also works together, e. g.:
So, in your case I would suggest:
report builds the document and before doing this, you could get/clone the other repo and use it content. Therefore you create a project access token in the analysis-repo and store it as a (mask) variable in the report-repo. Then in the .gitlab-ci.yml you do something like git clone https://$tokennamevariable:$tokenvariable@url
and use the content somehow.
@Daniel.Mohr @a.pirogov How complicated would it be to enable your pipeline to access files from other GitLab projects (in the same subgroup)?
I am just asking because at the moment the TF Survey has two projects - one for the analysis and one for the report. At the moment we are still working on the anaylsis and updating our outputs, while we simultaneously write the report. So it would be great to access the recent version when the pipeline in the document repo runs.
If it is too complicated, do you have an idea how we could easiliy do a workaround?
At the moment it is not possible to have multiple affiliations for an author.
So the file is already there, but no one is using it.
Then I don't need a seperate file, but I would like to encourage everyone to list their references in that file. Would that be part of a style guide? Or could we extract the inline references in the pipeline?
In pandoc-latex-build-demonstration it is already demonstrated how to use a literature.bib
. And the same works here.
@clemster From the literature.bib
there is of course a bbl
-file created during the build. Do you think this is interesting after creating the pdf
-file? Should it be available in the job artifacts?
The inline references are typical for markdown files. markdown does not provide an other feature. markdown works for a single document. It is out of scope of markdown to split the work in many files. Therefore the gitlab web front end does also only handle inline references.