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

Jason Ekstrand jason at jlekstrand.net
Fri Jun 1 17:43:42 UTC 2018


On Fri, Jun 1, 2018 at 9:57 AM, Laura Ekstrand <laura at 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 <daniel at fooishbar.org> wrote:
>
>> Hi,
>>
>> On 1 June 2018 at 11:23, Eric Engestrom <eric.engestrom at 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180601/0c0536e0/attachment-0001.html>


More information about the mesa-dev mailing list