On Friday, 2018-06-01 11:16:29 +0100, Daniel Stone wrote: > On 1 June 2018 at 11:10, Eric Engestrom <eric.engest...@intel.com> wrote: > > On Thursday, 2018-05-31 14:59:58 -0700, Jason Ekstrand wrote: > >> If you could deal with Daniel's feedback and v3 just this patch sooner > >> rather than later, that would be good. I'd like to merge it before we > >> switch to gitlab so we can start using gitlab CI artifacts for the website > >> right away. That way, it'll be ready for when the rest of the series > >> lands. > > > > It's unnecessary, but it doesn't hurt; leaving it in is fine. > > You can land it now if you want, with my R-b as mentioned in v1 :) > > Yeah, I really do not mind in the slightest if my suggestion gets > taken or not. It's not a correctness fix and doesn't actually matter > at all bar cosmetics. > > 'only: master' is a really good catch though, and should _definitely_ > be included. > > GitLab Pages is served by an internal daemon rather than external, and > doesn't take branches, tags, MRs, etc into account: whenever a CI > pipeline that generates pages is triggered, the site will be replaced > with that content. > > 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"? > > Cheers, > Daniel _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev