I have created a custom brew formula for go binary. so when I update the main code repo, I need to manually update the homebrew-X formula to change the version or say update the shasum 256 of that.
can someone please help how can I update the shasum 256 and version auto?
You can automate it with goreleaser help - see brew
here is a configuration example of how it can be used with goreleaser (note it's referring to the private repository).
brews:
- name: app-cli
homepage: 'https://github.com/xendit/app-cli'
description: 'app-cli binary distribution using homebrew.'
folder: Formula
download_strategy: GitHubPrivateRepositoryReleaseDownloadStrategy
custom_require: "lib/private_strategy"
commit_author:
name: goreleaserbot
email: goreleaser#xendit.co
tap:
owner: username
name: app-cli
install: |
bin.install "app-cli"
Goreleaser itself can be automated with any ci system.
Related
I got an error of ansible and I'm very new to ansible.
I'm trying to install homebrew packages by ansible. I made directories and files following an article of setting up MacOS with ansible.
I made homebrew/tasks/main.yml
- name: Add homebrew tap repository
homebrew_tap: tap={{ item.name }} state=present
with_items:
- "{{ homebrew_taps }}"
- name: Update homebrew
homebrew: update_homebrew=yes
- name: Install brew packages
homebrew:
name={{ item.name }}
state={{ item.state | default('latest') }}
install_options={{
item.install_options | default('latest') | join(',')
if item.install_options is not string
else item.install_options
}}
with_items:
"{{ homebrew_packages }}"
- name: Install cask packages
homebrew_cask:
name={{ item.name }}
state={{ item.state | default('installed') }}
with_items:
- "{{ homebrew_cask_packages }}"
and homebrew/vars/main.yml
homebrew_taps:
- { name: homebrew/cask }
- { name: homebrew/cask-versions }
- { name: homebrew/cask-fonts }
- { name: homebrew/core }
homebrew_packages:
- { name: fish, state: present }
#- { name: tree }
#- { name: asdf }
#- { name: gh }
#- { name: lazygit }
Then I run HOMEBREW_CASK_OPTS="--appdir=~/Applications" ansible-playbook -i hosts -K exec.yml. But it does not work.
It throws an error and shows this message:
TASK [homebrew : Install brew packages] *****************************************
failed: [localhost] (item={'name': 'fish', 'state': 'present'}) => {"ansible_loop_var": "item", "changed": false, "item": {"name": "fish", "state": "present"}, "msg": "Usage: brew install [options] formula|cask [...]\n\nInstall a formula or cask. Additional options specific to a formula may be\nappended to the command.\n\nUnless HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK is set, brew upgrade or brew\nreinstall will be run for outdated dependents and dependents with broken\nlinkage, respectively.\n\nUnless HOMEBREW_NO_INSTALL_CLEANUP is set, brew cleanup will then be run for\nthe installed formulae or, every 30 days, for all formulae.\n\nUnless HOMEBREW_NO_INSTALL_UPGRADE is set, brew install formula will\nupgrade formula if it is already installed but outdated.\n\n -d, --debug If brewing fails, open an interactive\n debugging session with access to IRB or a\n shell inside the temporary build directory.\n -f, --force Install formulae without checking for\n previously installed keg-only or non-migrated\n versions. When installing casks, overwrite\n existing files (binaries and symlinks are\n excluded, unless originally from the same\n cask).\n -v, --verbose Print the verification and postinstall steps.\n -n, --dry-run Show what would be installed, but do not\n actually install anything.\n --formula, --formulae Treat all named arguments as formulae.\n --ignore-dependencies An unsupported Homebrew development flag to\n skip installing any dependencies of any kind.\n If the dependencies are not already present,\n the formula will have issues. If you're not\n developing Homebrew, consider adjusting your\n PATH rather than using this flag.\n --only-dependencies Install the dependencies with specified\n options but do not install the formula\n itself.\n --cc Attempt to compile using the specified\n compiler, which should be the name of the\n compiler's executable, e.g. gcc-7 for GCC\n 7. In order to use LLVM's clang, specify\n llvm_clang. To use the Apple-provided\n clang, specify clang. This option will only\n accept compilers that are provided by\n Homebrew or bundled with macOS. Please do not\n file issues if you encounter errors while\n using this option.\n -s, --build-from-source Compile formula from source even if a\n bottle is provided. Dependencies will still\n be installed from bottles if they are\n available.\n --force-bottle Install from a bottle if it exists for the\n current or newest version of macOS, even if\n it would not normally be used for\n installation.\n --include-test Install testing dependencies required to run\n brew test formula.\n --HEAD If formula defines it, install the HEAD\n version, aka. main, trunk, unstable, master.\n --fetch-HEAD Fetch the upstream repository to detect if\n the HEAD installation of the formula is\n outdated. Otherwise, the repository's HEAD\n will only be checked for updates when a new\n stable or development version has been\n released.\n --keep-tmp Retain the temporary files created during\n installation.\n --debug-symbols Generate debug symbols on build. Source will\n be retained in a cache directory. \n --build-bottle Prepare the formula for eventual bottling\n during installation, skipping any\n post-install steps.\n --bottle-arch Optimise bottles for the specified\n architecture rather than the oldest\n architecture supported by the version of\n macOS the bottles are built on.\n --display-times Print install times for each package at the\n end of the run.\n -i, --interactive Download and patch formula, then open a\n shell. This allows the user to run\n ./configure --help and otherwise determine\n how to turn the software package into a\n Homebrew package.\n -g, --git Create a Git repository, useful for creating\n patches to the software.\n --overwrite Delete files that already exist in the prefix\n while linking.\n --cask, --casks Treat all named arguments as casks.\n --[no-]binaries Disable/enable linking of helper executables\n (default: enabled).\n --require-sha Require all casks to have a checksum.\n --[no-]quarantine Disable/enable quarantining of downloads\n (default: enabled).\n --skip-cask-deps Skip installing cask dependencies.\n --zap For use with brew reinstall --cask. Remove\n all files associated with a cask. May remove\n files which are shared between applications.\n --appdir Target location for Applications (default:\n /Applications).\n --colorpickerdir Target location for Color Pickers (default:\n ~/Library/ColorPickers).\n --prefpanedir Target location for Preference Panes\n (default: ~/Library/PreferencePanes).\n --qlplugindir Target location for QuickLook Plugins\n (default: ~/Library/QuickLook).\n --mdimporterdir Target location for Spotlight Plugins\n (default: ~/Library/Spotlight).\n --dictionarydir Target location for Dictionaries (default:\n ~/Library/Dictionaries).\n --fontdir Target location for Fonts (default:\n ~/Library/Fonts).\n --servicedir Target location for Services (default:\n ~/Library/Services).\n --input-methoddir Target location for Input Methods (default:\n ~/Library/Input Methods).\n --internet-plugindir Target location for Internet Plugins\n (default: ~/Library/Internet Plug-Ins).\n --audio-unit-plugindir Target location for Audio Unit Plugins\n (default:\n ~/Library/Audio/Plug-Ins/Components).\n --vst-plugindir Target location for VST Plugins (default:\n ~/Library/Audio/Plug-Ins/VST).\n --vst3-plugindir Target location for VST3 Plugins (default:\n ~/Library/Audio/Plug-Ins/VST3).\n --screen-saverdir Target location for Screen Savers (default:\n ~/Library/Screen Savers).\n --language Comma-separated list of language codes to\n prefer for cask installation. The first\n matching language is used, otherwise it\n reverts to the cask's default language. The\n default value is the language of your system.\n -q, --quiet Make some output more quiet.\n -h, --help Show this message.\nError: invalid option: --t"}
Do you have ideas of this issue? Thank you for reading my question.
I've released MooseX::Extended to the CPAN (github repository here).
I'm trying to set up github actions and the linux tests run just fine. However, (Windows is failing with this error:
Configuring true-v1.0.2 ... OK
==> Found dependencies: Function::Parameters
--> Working on Function::Parameters
Fetching http://www.cpan.org/authors/id/M/MA/MAUKE/Function-Parameters-2.001003.tar.gz ... OK
Configuring Function-Parameters-2.001003 ... OK
Building Function-Parameters-2.001003 ... OK
Successfully installed Function-Parameters-2.001003
! Installing true failed. See C:\Users\RUNNER~1\.cpanm\work\1653412748.5640\build.log for details. Retry with --force to force install it.
Building true-v1.0.2 ... FAIL
Of course, I can't see that C:\Users\RUNNER~1\.cpanm\work\1653412748.5640\build.log to understand what happened.
The true module passes its CPAN testers tests on Windows, so I don't know why it's failing in Github Actions.
My workflow looks like this:
# Hacked from https://github.com/skaji/perl-github-actions-sample/blob/master/.github/workflows/windows.yml
# See also: https://perlmaven.com/github-actions-running-on-3-operating-systems
name: windows
on:
push:
branches:
- '*'
tags-ignore:
- '*'
pull_request:
jobs:
perl:
runs-on: windows-latest
strategy:
fail-fast: false
matrix:
perl-version:
- '5.20'
- '5.22'
- '5.24'
- '5.26'
- '5.28'
- '5.30'
- '5.32'
- '5.34'
- 'latest'
steps:
- uses: actions/checkout#v2
- name: Set up Perl
run: |
choco install strawberryperl
echo "C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin" >> $GITHUB_PATH
- name: perl -V
run: perl -V
- name: Install Dependencies
run: curl -sL https://git.io/cpm | perl - install -g --show-build-log-on-failure Dist::Zilla
- name: Run Tests
run: |
dzil authordeps --missing | cpanm --notest
dzil listdeps --author --missing | cpanm --notest
dzil test --author --release
This is the PR to which the actions are attached.
I don't have access to a Windows box. Does anyone know what I missed?
Since GitHub Actions/Workflows uses a container for Windows that already has a version of Strawberry Perl pre-installed, it will not allow you to install any other version. You cannot remove the version of Perl that's pre-installed, and removing/installing a new one via Chocolatey is also next to impossible. If you re-install the version from Chocolatey that's already on the container, it seems to allow this, but it's basically a NOOP for you as a test setup.
The container also has MinGW installed; this can be bad for us as well. Having MinGW installed separately prevents XS modules from building (whether they be a dependency or if your own module is an XS module). Granted, this only happens if MinGW appears in the PATH ahead of your Perl install, but when you remove one Perl and add another, you're going to hit this problem.
To get around this, the best course of action is to remove the currently installed version of Perl from the PATH environment variable, along with their currently installed version of MinGW. Once both are safely out of the PATH, you can install a Portable[1] Strawberry Perl, put that Perl's paths in your PATH and begin testing with a fresh install of Strawberry Perl. GitHub recently broke our ability to do this directly in an Action YAML file.
That all sounds like a big headache, but it's really not. There's an Action available to us for this very purpose: actions-setup-perl. With this action you can easily test using any version of Perl you like. So, if you're hearing someone report a bug on Perl v5.26 on Windows, you can now add that to your matrix and test easily without the need for any back-and-forth from the user:
name: windows
on:
push:
branches:
- '*'
tags-ignore:
- '*'
pull_request:
jobs:
perl:
runs-on: windows-latest
strategy:
fail-fast: true
matrix:
perl-version:
- '5.30'
# - '5.28'
# - '5.26'
# - '5.24'
# - '5.22'
# - '5.20'
# - '5.18'
# - '5.16'
- '5.14'
steps:
- name: Setup perl
uses: shogo82148/actions-setup-perl#v1
with:
perl-version: ${{ matrix.perl-version }}
distribution: strawberry
- name: Set git to use LF
run: |
git config --global core.autocrlf false
git config --global core.eol lf
- uses: actions/checkout#v2
- name: perl -V
run: perl -V
- name: Ensure we have a working toolchain
run: cpanm ExtUtils::Manifest App::cpanminus
- name: Install Dependencies
run: cpanm -n --installdeps .
- name: Run Tests
run: cpanm --test-only -v .
[1] Portable versions of Strawberry Perl are zipped up, already compiled versions of Perl that do not require you to run an installer on Windows. This means that no heightened privileges are required, etc. You just unzip the archive in the directory you want to run Perl from, then add the relevant paths to Perl in your $env:PATH variable. It takes away any annoyances of build irregularities, etc. I've found it to be the most sane way to test on Windows.
I'm trying to download the latest artifacts of a Cirrus CI build on a Github repo, and according to the docs, it is
https://api.cirrus-ci.com/v1/artifact/github/<USER OR ORGANIZATION>/<REPOSITORY>/<TASK NAME OR ALIAS>/<ARTIFACTS_NAME>/<PATH>.
Applying it to https://github.com/SDP-Rock-Paper-Scissors/RockPaperScissors, I get https://api.cirrus-ci.com/v1/artifact/github/SDP-Rock-Paper-Scissors/RockPaperScissors/check_android/jacoco_coverage/app/build/reports/jacoco/jacocoTestReport/html/index.html but that doesn't seem to work, am I doing something wrong ?
Add Alias to your task and download it by alias.
wheel_macos_arm_task:
only_if: $CIRRUS_BRANCH == 'master'
name: macosx • Apple Silicon
alias: wheel_macos_arm
macos_instance:
image: ghcr.io/cirruslabs/macos-monterey-xcode
env:
PATH: /opt/homebrew/opt/python#3.10/bin:$PATH
install_pre_requirements_script:
- brew install python#3.10
- ln -s python3 /opt/homebrew/opt/python#3.10/bin/python
install_cibuildwheel_script:
- python -m pip install cibuildwheel==2.11.4
run_cibuildwheel_script:
- cibuildwheel
wheels_artifacts:
path: "wheelhouse/*"
https://api.cirrus-ci.com/v1/artifact/github/GITHUB_USERNAME/PROJECT_NAME/wheel_macos_arm/wheels.zip
I have installed bioconda following the instructions at https://bioconda.github.io/user/install.html#set-up-channels. Then I tried
conda install bwa
conda install bcftools
conda install plink2
They all installed fine. However, when I tried
conda install bcftools-gtc2vcf-plugin
or
conda install -c bioconda bcftools-gtc2vcf-plugin
as instructed at https://bioconda.github.io/recipes/bcftools-gtc2vcf-plugin/README.html, I got errors as follows:
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
PackagesNotFoundError: The following packages are not available from current channels:
- bcftools-gtc2vcf-plugin
Current channels:
- https://conda.anaconda.org/bioconda/osx-64
- https://conda.anaconda.org/bioconda/noarch
- https://conda.anaconda.org/conda-forge/osx-64
- https://conda.anaconda.org/conda-forge/noarch
- https://repo.anaconda.com/pkgs/main/osx-64
- https://repo.anaconda.com/pkgs/main/noarch
- https://repo.anaconda.com/pkgs/r/osx-64
- https://repo.anaconda.com/pkgs/r/noarch
To search for alternate channels that may provide the conda package you're
looking for, navigate to
https://anaconda.org
and use the search bar at the top of the page.
Any help would be highly appreciated.
Thanks in advance!
I would advise (as of 2020-01-06) not to use the bcftools-gtc2vcf-plugin as it is an old version missing many features compared to the current version. I would advise either to compile from source (https://github.com/freeseek/gtc2vcf) or alternatively to download pre-compiled binaries (https://personal.broadinstitute.org/giulio/gtc2vcf) that should work on systems with ≥GLIBC_2.3 installed (and making sure you are running the latest version of BCFtools)
If you get the error:
No functional bcftools plugins were found in
BCFTOOLS_PLUGINS="/Users/moxu/xbin/seq/bcftools/plugins".
- Is the plugin path correct?
- Run "bcftools plugin -lv" for more detailed error output.
Could not load "gtc2vcf".
(a bcftools plugin bug that the maintainers will fix soon), can you try to run one of the following commands instead:
$ bcftools plugin gtc2vcf -vv
$ bcftools +gtc2vcf -vv
$ bcftools plugin /Users/moxu/xbin/seq/bcftools/plugins/gtc2vcf.so -vv
$ bcftools +/Users/moxu/xbin/seq/bcftools/plugins/gtc2vcf.so -vv
You should get a reason for why the plugin is not loading. A typical error message could look like this:
/Users/moxu/xbin/seq/bcftools/plugins/gtc2vcf.so:
dlopen .. /lib64/libc.so.6: version `GLIBC_2.3' not found (required by /Users/moxu/xbin/seq/bcftools/plugins/gtc2vcf.so)
Is it possible to separate the install deps and caching from the build of the source code?
I have:
sudo: required
language: cpp
matrix:
include:
- env: GCC_VERSION="4.9"
os: linux
dist: trusty
compiler: gcc
cache:
directories:
- /usr/local/include
- /usr/local/lib
- /usr/local/share
addons:
apt:
packages:
- gcc-4.9
- g++-4.9
sources:
- ubuntu-toolchain-r-test
# Install dependencies
install:
- export BUILD_DEPS="OFF"
- export BUILD_GRSF="ON"
- export CHECKOUT_PATH=`pwd`;
- chmod +x $CHECKOUT_PATH/travis/install_${TRAVIS_OS_NAME}.sh
- . $CHECKOUT_PATH/travis/install_${TRAVIS_OS_NAME}.sh
script:
- chmod +x $CHECKOUT_PATH/travis/build.sh
- . $CHECKOUT_PATH/travis/build.sh
notifications:
email: false
Because my build takes too long (more than 50 minutes with building dependencies and the source code) I proceed in the following way:
I set
BUILD_DEPS="ON" # build only deps
BUILD_GRSF="OFF"
which only builds the dependencies and caches them, afterwards I set
BUILD_DEPS="OFF"
BUILD_GRSF="ON" # build only source
in the .travis.yaml file which then builds only the source code.
This seems to work but is cumbersome? Is there a better solution to this? Maybe directly on travis modifying the .travis.yaml and make a new commit "travis cached, build source now". which will then trigger another travis build (which now builds the source)
Your dependency install script could look for a marker file your script leaves after successful installation in a cached dir and only if that's not found you would re-run the build.
That way you don't need any modifications to the travis spec at least.
It seems travis can only cache in $HOME:
https://github.com/travis-ci/travis-ci/issues/6115#issuecomment-222817367