On Fri, Jun 1, 2018 at 9:57 AM, Laura Ekstrand <la...@jlekstrand.net> wrote:
> Daniel, > > I literally just followed the example: > > https://docs.gitlab.com/ee/ci/yaml/#pages > > As I recall, there's a recursive loop if you don't use .public. > Ah, I see what's going on. The glob character "*" will list all directories that don't have a . so "cp * public" will turn into "cp thing1 thing2 public thing3 public" and cp will explode. In this very simple case, I think we can not run cp at all and just do pages: stage: deploy script: - cp docs public artifacts: paths: - public or possibly even: pages: stage: deploy script: artifacts: paths: - docs Though I think having a cp in there is a good idea. > On Fri, Jun 1, 2018, 4:17 AM Daniel Stone <dan...@fooishbar.org> wrote: > >> Hi, >> >> On 1 June 2018 at 11:23, Eric Engestrom <eric.engest...@intel.com> wrote: >> > On Friday, 2018-06-01 11:16:29 +0100, Daniel Stone wrote: >> >> https://docs.gitlab.com/ee/user/project/pages/introduction.html >> >> > Be aware that Pages are by default branch/tag agnostic and their >> >> > deployment relies solely on what you specify in .gitlab-ci.yml. If >> >> > you don't limit the pages job with the only parameter, whenever >> >> > a new commit is pushed to whatever branch or tag, the Pages will be >> >> > overwritten. >> > >> > Hmm, so that means we can't get MRs to build artifacts? >> > Is there a way to say "build: always; deploy: only: master"? >> >> Right, it's a little awkward, but still possible: >> https://docs.gitlab.com/ee/user/project/pages/getting_ >> started_part_four.html#stages >> >> Basically, in master you build to and capture 'public', and off master >> you build to and capture another path. If you don't have an artifact >> with public/ in it, the site won't get updated, but you can still pull >> the artifacts. >> >> (I'd typed out roughly the same thing before thinking 'there must be a >> better way' and finding the docs. The only difference is that I'd had >> separate build/deploy stages to avoid duplicating the build >> instructions.) >> >> Cheers, >> Daniel >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
