I am currently working on setting up a workflow for my Github Pages site. I have successfully created html files from Python and now only need to publish. I am using this Github Action for doing that. However, my builds fail with the error message:
github-pages 222 | Error: No such file or directory # rb_check_realpath_internal - /github/workspace/bin/python3
I have the file /bin/python3 in my repository and it should additionally not be used for that build shouldnt it?
Why is it getting used and how do I fix it?
Note: I am not limited to this specific action. If there is another one that works better I would be happy to use it!
This is my worker file right now:
name: Jekyll site CI
on:
push:
branches: [ gh-pages ]
pull_request:
branches: [ gh-pages ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout#v2.4.0
- name: install python
uses: actions/setup-python#v2
with:
python-version: "3.9.2"
- name: install python packages
run: |
python -m pip install --upgrade pip
pip install jinja2
- name: run python script
run: python app.py
- name: Deploy to GitHub Pages
if: success()
uses: crazy-max/ghaction-github-pages#v2.5.0
with:
build_dir: ./
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Related
I have enabled Github actions to create Tech docs after a commit. Below is the workflow file written to create Md files. But "techdocs-cli generate --no-docker --verbose" command fails with the below error. Can someone please help with the issue?
Failed to generate docs from /home/runner/work/myapp3/myapp3 into /home/runner/work/myapp3/myapp3/site; caused by unknown error 'Command mkdocs failed, exit code: 1'
workflow file:
name: Publish TechDocs Site
on:
push:
branches: master
jobs:
publish-techdocs-site:
runs-on: ubuntu-latest
env:
TECHDOCS_S3_BUCKET_NAME: XXX
AWS_ACCESS_KEY_ID: XXX
AWS_SECRET_ACCESS_KEY: XXX
AWS_REGION: XXX
ENTITY_NAMESPACE: 'default'
ENTITY_KIND: 'Component'
ENTITY_NAME: ‘XXX’
steps:
- name: Checkout code
uses: actions/checkout#v2
- uses: actions/setup-node#v2
- uses: actions/setup-python#v2
- name: Install techdocs-cli
run: sudo npm install -g #techdocs/cli
- name: Install mkdocs and mkdocs plugins
run: python -m pip install mkdocs-techdocs-core==1.*
- name: Generate docs site
run: techdocs-cli generate --no-docker --verbose
- name: Publish docs site
run: techdocs-cli publish --publisher-type awsS3 --storage-name $TECHDOCS_S3_BUCKET_NAME --entity $ENTITY_NAMESPACE/$ENTITY_KIND/$ENTITY_NAME
I had the same issue and it was resolved once you had the right folder structure where you have the mkdocs.yml file.
As long as you have a docs folder in the same root structure with the .md file that needs to be published.
The same .md file needs to be configured in the navigation section of the mkdocs.yml file as well
I am creating a github action to run on a schedule. The purpose of the action is to pull my pypi package pip install alphavantage_api_client then run python app.py to verify my published package is working correctly. To make this work, I need to exclude the internal client source code with something like paths-ignore but it's not working. How do I exclude a directory within a github action? Here is my github action config:
name: Daily End to End Tests with Alphavantage API PyPi
on:
schedule:
- cron: "0 */12 * * *"
paths-ignore:
- alphvantage_api_client
permissions:
contents: read
env:
ALPHAVANTAGE_API_KEY: "${{ secrets.ALPHAVANTAGE_API_KEY }}"
jobs:
build:
runs-on: ubuntu-latest
timeout-minutes: 20
environment:
name: "Daily End to End Tests"
steps:
- uses: actions/checkout#v3
- name: Set up Python 3.10
uses: actions/setup-python#v3
with:
python-version: "3.10"
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install alphavantage_api_client
python app.py
The error i get from the above is a syntax error with the paths-ignore, so i can see there is a problem.
I've referenced the documentation here
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-excluding-paths=
but i don't see a way to exclude paths for a scheduled action. Can someone point me in the right direction?
On a github repository my_repo, I could correctly set up github actions to trigger build, tests and documentation:
name: CMake
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
env:
# Customize the CMake build type here (Release, Debug, RelWithDebInfo, etc.)
BUILD_TYPE: Release
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Install dependencies
run: sudo apt-get install -y --no-install-recommends libboost-all-dev libgdal-dev doxygen graphviz
- name: Configure CMake
run: cmake -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}}
- name: Build
run: cmake --build ${{github.workspace}}/build --config ${{env.BUILD_TYPE}}
- name: Test
working-directory: ${{github.workspace}}/build
run: ctest -C ${{env.BUILD_TYPE}}
- name: Docs
working-directory: ${{github.workspace}}/build
run: make doc
I also implemented Release Drafter to automate the process of bumping versions:
name: Release Drafter
on:
push:
branches:
- master
pull_request:
types: [opened, reopened, synchronize]
jobs:
update_release_draft:
runs-on: ubuntu-latest
steps:
- uses: release-drafter/release-drafter#v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Now, I would like to automate the following:
a major version is released in the repo my_repo
this triggers an event in my Github Pages repo
the documentation is built in my Github Pages repo in the folder softs/my_repo/docs
the website is published (that is equivalent to commiting the changes and pushing the master branch)
I don't exactly know how to implement that. Should I write a github workflow in my Github pages to "listen" what is happening in the my_repo project? Also, I can I forward the version from the my_repo to Doxygen?
I ended up being able to reach my goals. I will post this sample code in case it could benefit the next beginner with Github Action to automate the documentation building:
name: CMake
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
env:
# Customize the CMake build type here (Release, Debug, RelWithDebInfo, etc.)
BUILD_TYPE: Release
jobs:
build:
# The CMake configure and build commands are platform agnostic and should work equally well on Windows or Mac.
# You can convert this to a matrix build if you need cross-platform coverage.
# See: https://docs.github.com/en/free-pro-team#latest/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
# we want to find git tags to pass version to doxygen
fetch-depth: 0
- name: Install quetzal and Doxygen dependencies
run: sudo apt-get install -y --no-install-recommends libboost-all-dev libgdal-dev doxygen graphviz
- name: Configure CMake
# Configure CMake in a 'build' subdirectory. `CMAKE_BUILD_TYPE` is only required if you are using a single-configuration generator such as make.
# See https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html?highlight=cmake_build_type
run: cmake -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{env.BUILD_TYPE}}
- name: Build
# Build your program with the given configuration
run: cmake --build ${{github.workspace}}/build --config ${{env.BUILD_TYPE}}
- name: Test
working-directory: ${{github.workspace}}/build
# Execute tests defined by the CMake configuration.
# See https://cmake.org/cmake/help/latest/manual/ctest.1.html for more detail
run: ctest -C ${{env.BUILD_TYPE}}
- name: Generate documentation
working-directory: ${{github.workspace}}/build
# this is defined in the repo docs/CMakeLists.txt file
run: make docs
- name: Moving Files
run: |
mv ${{github.workspace}}/build/docs/html ./docs/api
# Deploy to GitHub Pages
- name: Deploy
uses: peaceiris/actions-gh-pages#v3
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
publish_dir: ./
In the project/docs/CMakeLists.txt:
# look for Doxygen package
# Require dot, treat the other components as optional
find_package(Doxygen
REQUIRED dot
OPTIONAL_COMPONENTS mscgen dia)
if(DOXYGEN_FOUND)
# exclude sqlite code
set(DOXYGEN_EXCLUDE_PATTERNS
*/sqlite3/*
)
# doxygen settings can be set here, prefixed with "DOXYGEN_"
set(DOXYGEN_PROJECT_NAME "my-project")
set(DOXYGEN_INPUT "mainpage.md")
set(DOXYGEN_USE_MDFILE_AS_MAINPAGE "mainpage.md")
set(DOXYGEN_EXCLUDE_PATTERNS "README.md")
set(DOXYGEN_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/docs")
# this target will only be built if specifically asked to.
# run "make docs" to create the doxygen documentation
doxygen_add_docs(
docs
${PROJECT_SOURCE_DIR}
COMMENT "Generate API-documents for NoteSearch."
)
endif(DOXYGEN_FOUND)
To automatically retrieve the version number and pass it to Doxygen (as well as to the C++ code), I could adapt the solution given by Brian Milco here: https://ipenguin.ws/2012/11/cmake-automatically-use-git-tags-as.html .
They posted the solution in 2012, so there may be easier ways to do the same thing in 2022. But, as far as I am concerned, it works for me!
In the root CMakeLists.txt:
cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
#
# VERSIONING
#
# Appends the cmake/modules path to MAKE_MODULE_PATH variable.
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules ${CMAKE_MODULE_PATH})
include(GetGitRevisionDescription)
git_describe(VERSION --tags --dirty=-d)
#parse the version information into pieces.
string(REGEX REPLACE "^v([0-9]+)\\..*" "\\1" VERSION_MAJOR "${VERSION}")
string(REGEX REPLACE "^v[0-9]+\\.([0-9]+).*" "\\1" VERSION_MINOR "${VERSION}")
string(REGEX REPLACE "^v[0-9]+\\.[0-9]+\\.([0-9]+).*" "\\1" VERSION_PATCH "${VERSION}")
string(REGEX REPLACE "^v[0-9]+\\.[0-9]+\\.[0-9]+(.*)" "\\1" VERSION_SHA1 "${VERSION}")
set(VERSION_SHORT "${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_PATCH}")
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules/version.cpp.in
${CMAKE_CURRENT_BINARY_DIR}/version.cpp)
set(version_file "${CMAKE_CURRENT_BINARY_DIR}/version.cpp")
#Add the version_file to the executables being built or it won't compile.
#add_executable(${PROJECT_NAME} ${source_files} ${ui_files} ${version_file})
#
# PROJECT DESCRIPTION
#
project(
"project_name"
LANGUAGES CXX
VERSION ${VERSION_SHORT}
This sets the CMake project version to the automatically retrieved git version tag, and it is passed to the Doxygen module by a default on set(DOXYGEN_PROJECT_NUMBER $(PROJECT_VERSION).
A complete working solution can be find on my project at https://github.com/Becheler/quetzal-CoalTL/commit/2ef5851cc6a34391d7a9ea64fb7c7122feb23b0a
I'm trying to automate upload of my NuGet package using GitHub actions. I was hoping I could match the file name which includes the version number to avoid having to hardcode it in the action YML. It works if I hardcode the file name. I guess I just need to understand the syntax to use file pattern match. See last line of that code sample:
name: .NET
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
defaults:
run:
working-directory: ./Project
jobs:
build:
runs-on: windows-latest
steps:
- uses: actions/checkout#v2
- name: Setup .NET
uses: actions/setup-dotnet#v1
with:
dotnet-version: 5.0.x
- name: Restore dependencies
run: dotnet restore SharpLibHid.sln
- name: Build debug
run: dotnet build SharpLibHid.sln --no-restore -c Debug
- name: Build release
run: dotnet build SharpLibHid.sln --no-restore -c Release
- name: Test
run: dotnet test SharpLibHid.sln --no-build --verbosity normal
- name: Publish Nuget
run: dotnet nuget push './Hid/bin/Release/SharpLibHid.*.nupkg' --skip-duplicate -k ${{ secrets.NUGET_TOKEN }} --source https://api.nuget.org/v3/index.json
How do you use file matching pattern in GitHub actions run?
Here is a successful build with hardcoded path:
https://github.com/Slion/SharpLibHid/actions/runs/998451423
Here is a failed build with my attempt at pattern matching:
https://github.com/Slion/SharpLibHid/actions/runs/998464157
I have an action on master branch which on push/merge builds a package, uploads it to PyPI then checks out to develop branch, bumps version in develop branch and pushes to the origin of develop branch. Develop branch has an action that listens to push/merge and does a snapshot release.
When I push to develop the develop action works perfectly and does a snapshot release, but when master branch pushes, push is successful but the action does not get triggered. What am I missing?
Both actions are added below.
name: Build and Upload Package to PyPI | Master Branch
on:
push:
branches:
- master
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Set up Python
uses: actions/setup-python#v1
with:
python-version: '3.5'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install setuptools wheel twine
pip install GitPython
pip install bumpversion
- name: Strip 'snapshot' from version
run: sed -i 's/-snapshot//g' setup.py
- name: Build and publish
env:
TWINE_USERNAME: ${{ secrets.PYPI_USERNAME }}
TWINE_PASSWORD: ${{ secrets.PYPI_PASSWORD }}
TWINE_REPOSITORY_URL: https://pypi.domain.com
run: |
python setup.py sdist bdist_wheel
twine upload dist/*
- name: Bump Verison and Push to develop
run: |
git stash
git config --local user.email "name#email.com"
git config --local user.name "username"
git checkout develop
python bump_version.py
cat .bumpversion.cfg
git remote set-url --push origin https://username:$GITHUB_TOKEN#github.com/repo/path
git push origin develop
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
name: Build and Upload Package to PyPI | Develop Branch
on:
push:
branches:
- develop
jobs:
bumpTag_build_and_publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Set up Python
uses: actions/setup-python#v1
with:
python-version: '3.5'
- name: Install dependencies for setup
run: |
python -m pip install --upgrade pip
pip install setuptools wheel twine
- name: Build and publish
env:
TWINE_USERNAME: ${{ secrets.PYPI_USERNAME }}
TWINE_PASSWORD: ${{ secrets.PYPI_PASSWORD }}
TWINE_REPOSITORY_URL: https://pypi.domain.co,
run: |
python setup.py sdist bdist_wheel
twine upload dist/*
Provided secrets.GITHUB_TOKEN is intentionally not allowed to trigger workflows. As seen in documention:
(...) if an action pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.
If you need your automagic push to be "visible" by workflows, you need to create Personal Access Token, add it to repo secrets, and use that instead of GITHUB_TOKEN.
Note that GitHub assumes that you know what you're doing, if you use non-stock token - which means preventing possible infinite loop is on you. While it's not a case in your scenario for now (develop branch does not push anything), it's worth to remember in case one of workflows will change some day.