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. 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
