xz/.github/workflows/freebsd.yml

# SPDX-License-Identifier: 0BSD

name: FreeBSD

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]
  workflow_dispatch:

jobs:
  FreeBSD-test:
    runs-on: ubuntu-latest
    name: Test xz on FreeBSD
    steps:
    - uses: actions/checkout@v4.1.6
    - name: Test in FreeBSD
      id: test
      uses: vmactions/FreeBSD-vm@d7b8fcc7711aa41ad45e8d9b737cf90f035a7e3d #v1.1.3
      with:
        usesh: true
        prepare: |
         pkg install -y autoconf automake gmake gettext-tools gtar libtool m4 po4a
        run: |
          set -e
          export LC_ALL=C LANG=C
          uname -a
          ./autogen.sh
          ./configure --enable-werror
          make
          make check VERBOSE=1
ci: add SPDX headers I've checked over each of these and they're straightforward applications of the relevant Github Actions. (cherry picked from commit 9a6761aa35ed84d30bd2fda2333a4fdf3f46ecdc) 2024-05-02 12:26:40 +00:00			`# SPDX-License-Identifier: 0BSD`

ci: add FreeBSD (cherry picked from commit 72c210336de26fb87a928160d025fa10a638d23b) 2024-04-13 22:49:26 +00:00			`name: FreeBSD`

			`on:`
			`push:`
			`branches: [ master ]`
			`pull_request:`
			`branches: [ master ]`
			`workflow_dispatch:`

			`jobs:`
			`FreeBSD-test:`
			`runs-on: ubuntu-latest`
			`name: Test xz on FreeBSD`
			`steps:`
ci: don't pin official GH actions via commit, just tag There's no real value in doing it via commit for official GH actions. We can keep using pinned commits for unofficial actions. It's hassle for no gain. Maybe going forward we can limit this further by only being paranoid for the jobs with any access to tokens. (cherry picked from commit 35f8649f08341639a627fd06350e938124ca3622) 2024-06-03 05:16:23 +00:00			`- uses: actions/checkout@v4.1.6`
ci: add FreeBSD (cherry picked from commit 72c210336de26fb87a928160d025fa10a638d23b) 2024-04-13 22:49:26 +00:00			`- name: Test in FreeBSD`
			`id: test`
CI: update FreeBSD, NetBSD, OpenBSD, Solaris actions Checked the changes and they're all innocuous. This should hopefully fix the "externally managed" pip error in these jobs that started recently. (cherry picked from commit dbca3d078ec581600600abebbb18769d3d713914) 2024-10-02 02:04:03 +00:00			`uses: vmactions/FreeBSD-vm@d7b8fcc7711aa41ad45e8d9b737cf90f035a7e3d #v1.1.3`
ci: add FreeBSD (cherry picked from commit 72c210336de26fb87a928160d025fa10a638d23b) 2024-04-13 22:49:26 +00:00			`with:`
			`usesh: true`
			`prepare: \|`
			`pkg install -y autoconf automake gmake gettext-tools gtar libtool m4 po4a`
			`run: \|`
ci: actually fail on FreeBSD Without "set -e" the job will always be successful. See vmactions/freebsd-vm#72 (cherry picked from commit 8641f0c24c041136670c975b23408184b45431bc) 2024-04-25 21:56:06 +00:00			`set -e`
ci: add FreeBSD (cherry picked from commit 72c210336de26fb87a928160d025fa10a638d23b) 2024-04-13 22:49:26 +00:00			`export LC_ALL=C LANG=C`
			`uname -a`
			`./autogen.sh`
			`./configure --enable-werror`
			`make`
			`make check VERBOSE=1`