[Mesa-dev] [PATCH v2 01/15] Added ci yaml file for Gitlab.

Eric Engestrom eric.engestrom at intel.com
Fri Jun 1 10:23:34 UTC 2018

On Friday, 2018-06-01 11:16:29 +0100, Daniel Stone wrote:
> On 1 June 2018 at 11:10, Eric Engestrom <eric.engestrom at 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

More information about the mesa-dev mailing list