DEV Community: epassaro

Make your videos Twitter (X) compatible

epassaro — Thu, 03 Aug 2023 16:00:28 +0000

If you are getting stuck at 99% while updating videos to Twitter, try this solution. It just requires having ffmpeg installed on the system and adding this function to your.bashrc:

twitterfix() { ffmpeg -i "$1" -c:v libx264 -crf 20 -preset slow -vf "crop=trunc(iw/2)*2:trunc(ih/2)*2, format=yuv420p" -c:a aac -movflags +faststart out.mp4 }

Usage example:

$ twitterfix my_video.mp4
$ ls
my_video.mp4 out.mp4

[FIX] Read-only file system after waking up from suspend

epassaro — Sun, 30 Jul 2023 20:35:23 +0000

A new laptop has arrived and of course new problems arise after installing Linux. But this time the problem looked familiar.

This time I was working with an ASUS laptop with an Intel 11th Gen processor and an Intel NVMe SSD.

First thing I did was checking if the evil s2idle sleep mode was enabled, and I that was exactly the case.

$ cat /sys/power/mem_sleep
[s2idle] deep

The S3 deep mode was available, so this time I didn't need to patch the ACPI table. Then, I just added "mem_sleep_default=deep" line to the GRUB_CMDLINE_LINUX_DEFAULT parameter in /etc/default/grub and updated GRUB according to my distribution.

Now I can suspend and wake up the system without any problem!

Remove patterns in openSUSE

epassaro — Mon, 19 Jun 2023 02:55:59 +0000

To remove a pattern in openSUSE just type the following command.

sudo zypper remove -u pattern:<pattern_name>

For example:

sudo zypper remove -u pattern:kvm_server pattern:kvm_tools

Identify and Report Vulnerable Dependencies in Conda-Based Projects with GitHub Actions

epassaro — Mon, 22 May 2023 22:01:40 +0000

What I built

A GitHub Actions workflow that scans your Conda environment files for common vulnerabilities and exposures (CVE).

It's worth mentioning that Dependabot does not have support for Conda environment files, and GitHub developers have stated that there are no plans to add this feature in the foreseeable future.

Category Submission:

DIY Deployments

App Link

Screenshots

Description

Looking for a solution like Dependabot for your Conda-based project? Strengthen your repository's security with this reliable GitHub Actions reusable workflow!.

Implementing this workflow is straightforward. Just provide the path to your Conda environment file in YAML format, and let the workflow effortlessly handle the rest.

Powered by jake, an open-source package from the Sonatype Community, this workflow checks your environments for vulnerable open-source packages using the trusted OSS Index.

If any vulnerabilities are detected, the workflow will either open a new issue or update an existing one, listing the known CVEs and affected packages.

Furthermore, you have the option to ignore specific CVEs by providing a text file. Customize your security measures according to your needs.

And the best part is that this is not restricted just to Python packages! Packages in any progamming language are supported as far as they are distributed by the Conda package manager.

Link to Source Code

https://github.com/epassaro/conda-deps-check

Permissive License

MIT License

Background (What made you decide to build this particular app? What inspired you?)

The motivation to build this app stemmed from my personal experience as a solo developer working on Conda-based projects. It became evident that there was a significant gap in the availability of tools like Dependabot that could effectively address security concerns in this context.

Driven by the desire to bolster the security of my own projects, I embarked on the task of developing tools that could offer similar functionality to Dependabot. Participating in this hackathon provided the perfect opportunity to jumpstart this endeavor.

I am fully committed to the continuous improvement and expansion of these workflows beyond the hackathon.

How I built it (How did you utilize GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)

I built this workflow as a reusable solution, and it was my first time working with this type of workflow. While I had some familiarity with Azure Pipelines templates, reusable workflows offered a new and different experience. The beauty of reusable workflows is that they allow me to continue working on and adding features to the workflow, while making it easy for users to implement it in their repositories.

One of the great advantages of this workflow is its flexibility. Users can run different versions of the workflow based on release tags, branches, or commit SHA, giving them the ability to customize it according to their specific needs.

When it came to vulnerability scanning, I decided to use a specific version of jake that goes beyond checking vulnerabilities in just Python packages. It extends its reach to cover all packages distributed in the Conda ecosystem, which is a significant advantage compared to other alternatives available.

During the development process, I discovered the GitHub Advisory Database, which I wasn't previously aware of. This led me to create a nightly workflow that parses the database and generates a simple JSON file with package fixes for a given CVE. My plan is to use this information to enhance the generated report with more comprehensive details.

Additional Resources/Info

epassaro/ghadb-parser - GitHub Advisory Database Parser
epassaro/conda-deps-check-old - Previous version of this workflow, without using reusable workflows

Build your LaTeX documents with GitHub Actions

epassaro — Tue, 07 Dec 2021 01:36:18 +0000

My Workflow

LaTeX is a high-quality typesetting system, and it's the de facto standard for the communication and publication of scientific documents.

I think the Git version control system fits perfectly when it comes to collaborative, scientific writing. It's superior to the Google Docs style of Overleaf.

Installing a full LaTeX system takes up a considerable amount time and space on your hard drive. I heard about Tectonic during the PackagingCon 2021 and immediately I knew that's the kind of stuff I want to deploy on GitHub Actions.

Tectonic is a modernized, complete, self-contained TeX/LaTeX engine, powered by XeTeX and TeXLive. (...) Tectonic automatically downloads support files so you don’t have to install a full LaTeX system in order to start using it. If you start using a new LaTeX package, Tectonic just pulls down the files it needs and continues processing. The underyling “bundle” technology allows for completely reproducible document compiles.

Usage:

Choose one of the following options:

Open a Build request and submit your LaTeX code.
Fork the repository, apply your changes to build/main.tex and open a pull request.

A link with your results will be posted on the corresponding issue/pull request.

Demo:

Submission Category:

Wacky Wildcards

Yaml File or Link to Code

epassaro / texbuilder

Build and preview LaTeX documents with GitHub Actions

texbuilder

Build and preview LaTeX documents with GitHub Actions

Usage

Open a Build request and submit your LaTeX code.
Fork this repository, apply your changes to build/main.tex and open a pull request.

View on GitHub

Additional Resources / Info

Build a LaTeX document by opening an issue (or pull request)

epassaro ・ Dec 7 '21

#actionshackathon21 #github #latex

Build a LaTeX document by opening an issue (or pull request)

epassaro — Tue, 07 Dec 2021 00:47:28 +0000

I heard about Tectonic for the first time during the PackagingCon 2021 and immediately I knew that's the kind of stuff I want to deploy on GitHub Actions.

LaTeX is a high-quality typesetting system, and it's the de facto standard for the communication and publication of scientific documents. Installing a full LaTeX system takes up a considerable amount time and space on your hard drive.

Also, the reproducibility of these documents is not trivial. That's where Tectonic comes in:

Tectonic is a modernized, complete, self-contained TeX/LaTeX engine, powered by XeTeX and TeXLive. (...) Tectonic automatically downloads support files so you don’t have to install a full LaTeX system in order to start using it. If you start using a new LaTeX package, Tectonic just pulls down the files it needs and continues processing. The underyling “bundle” technology allows for completely reproducible document compiles.

But... Why not just use Overleaf? Personally, I think the Git version control system fits perfectly when it comes to collaborative writing.

The workflow

This time, I wrote two different workflows: one to build from pull requests and other to build from issues.

I'm going to focus on the second one, because the other is very similar and easier to follow.

First, I created an issue template to submit LaTeX code:

Then, the workflow runs as you can see in the trigger section. Notice the job requires the [Build] label on the issue title.

name: issues

on:
  issues:
      types: [opened, edited]

env:
  REPO_URL: https://github.com/${{ github.repository_owner }}/${{ github.event.repository.name }}

jobs:
  build:
    if: startsWith(github.event.issue.title, '[Build]')
    runs-on: ubuntu-latest

The latest version of Tectonic is installed. dos2unix is required because the text from issue the body uses CRLF.

    steps:
      - uses: actions/checkout@v2

      - name: Install dependencies
        run: |
          sudo apt-get install dos2unix

          LAST_TAG=$(curl -s https://api.github.com/repos/tectonic-typesetting/tectonic/releases/latest | jq -r .tag_name)
          VERSION="${LAST_TAG##tectonic@}"

          wget -q https://github.com/tectonic-typesetting/tectonic/releases/latest/download/tectonic-$VERSION-x86_64-unknown-linux-gnu.tar.gz
          tar -zxf tectonic-$VERSION-x86_64-unknown-linux-gnu.tar.gz -C /usr/local/bin

The code from the body is extracted with a sed command and built with Tectonic. The result is uploaded as an artifact.

      - name: Extract code
        run: |
          echo $ISSUE_BODY | dos2unix -c mac > issue_body.txt
          sed -n '/%%build/, /%%dliub/{ /%%build/! { /%%dliub/! p } }' issue_body.txt > build/main.tex
        env:
          ISSUE_BODY: ${{ github.event.issue.body }}

      - name: Build PDF
        run: tectonic -X compile build/main.tex

      - uses: actions/upload-artifact@v2
        with:
          name: main
          path: build/main.pdf

Finally, the github-actions bot post the result of the workflow run as a comment in the corresponding issue.

Successive runs will update this comment, not creating new ones.

      - name: Find comment
        uses: peter-evans/find-comment@v1
        id: fc
        with:
          issue-number: ${{ github.event.issue.number }}
          comment-author: 'github-actions[bot]'
        if: always()

      - name: Post comment (success)
        uses: peter-evans/create-or-update-comment@v1
        with:
          issue-number: ${{ github.event.issue.number }}
          comment-id: ${{ steps.fc.outputs.comment-id }}
          edit-mode: replace
          body: |
            Hi, @${{ github.event.sender.login }}! :wave: <br>
            The workflow run has **succeeded**. [**Click here**](${{ env.LOG_URL }}) to download your results.
        env:
          LOG_URL: ${{ env.REPO_URL }}/actions/runs/${{ github.run_id }}?check_suite_focus=true

      - name: Post comment (failure)
        uses: peter-evans/create-or-update-comment@v1
        with:
          issue-number: ${{ github.event.issue.number }}
          comment-id: ${{ steps.fc.outputs.comment-id }}
          edit-mode: replace
          body: |
            Sorry, @${{ github.event.sender.login }}! :disappointed: <br>
            The workflow run has **failed**. [**Click here**](${{ env.LOG_URL }}) to see the build log.
        env:
          LOG_URL: ${{ env.REPO_URL }}/actions/runs/${{ github.run_id }}?check_suite_focus=true
        if: failure()

Future improvements

Currently, you need to download them and extract the ZIP file in order to see your results. This happens because workflows does not have access to the artifact ID while the job is running, and GitHub does not allow uploading unzipped archives.

An alternative is pushing the PDF to a specific branch or folder, but populating the repository with binary files is not a good idea.

Get the code

epassaro / texbuilder

Build and preview LaTeX documents with GitHub Actions

texbuilder

Build and preview LaTeX documents with GitHub Actions

Usage

Open a Build request and submit your LaTeX code.
Fork this repository, apply your changes to build/main.tex and open a pull request.

View on GitHub

Keep your research reproducible with conda-pack and GitHub Actions

epassaro — Sat, 27 Nov 2021 01:44:01 +0000

Reproducibility is a major principle underpinning the scientific method, and scientific software is not an exception.

Anaconda is a distribution of the Python and R programming languages for scientific computing with more than 25 million users. But, how reproducible is science made with Anaconda? And most important:

Do you think you will be capable of reproducing the results your research in the next 10 years?.

Currently, the reproducibility of Anaconda environments is not guaranteed. conda list --explicit provides just some kind of short term reproducibility.

For example, if you use packages from non-standard channels, the owner could delete them at any moment. Also, the resolved URLs could vary due to changes in package labels or storage.

There is an ongoing debate about how to unify the different available tools to solve this problem. In this workflow, I propose a simple but effective way to keep your environments reproducible using GitHub Actions and conda-pack:

conda-pack is a command line tool for creating archives of conda environments that can be installed on other systems and locations. This is useful for deploying code in a consistent environment —potentially where Python and/or conda isn’t already installed.

Every time you publish a new release of your code (e.g. a paper) on GitHub, the environment is solved, packed and uploaded as an asset.

name: pack

on:
  release:
    types: [published]

env:
  BASENAME: ${{ github.event.repository.name }}-${{ github.event.release.tag_name }} 

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Setup Mambaforge
        uses: conda-incubator/setup-miniconda@v2
        with:
            miniforge-variant: Mambaforge
            miniforge-version: latest
            environment-file: environment.yml
            activate-environment: my-env
            use-mamba: true

      - name: Freeze packages
        shell: bash -l {0}
        run: conda env export -n my-env > $BASENAME.yml

      - name: Install conda-pack
        shell: bash -l {0}
        run: mamba install -c conda-forge conda-pack

      - name: Pack environment
        shell: bash -l {0}
        run: conda pack -n my-env -o $BASENAME.tar.gz

      - name: Upload assets
        uses: AButler/upload-release-assets@v2.0
        with:
          files: '${{ env.BASENAME }}.{yml,tar.gz}'
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          release-tag: ${{ github.event.release.tag_name }}

Finally, follow the instructions to deploy an identical environment at any point in the future.

Get the code

epassaro / repro-conda-envs

An example repository on how to keep Anaconda environments reproducible in the long term with GitHub Actions

repro-conda-envs

An example repository on how to keep Anaconda environments reproducible in the long term with GitHub Actions

View on GitHub

Reproducible Anaconda environments with GitHub Actions

epassaro — Sat, 27 Nov 2021 01:21:52 +0000

My Workflow

Reproducibility is a major principle underpinning the scientific method, and scientific software is not an exception.

Anaconda is a distribution of the Python and R programming languages for scientific computing with more than 25 million users. But, how reproducible is science made with Anaconda? And most important:

Do you think you will be capable of reproducing the results your research in the next 10 years?.

Currently, the reproducibility of Anaconda environments is not guaranteed. conda list --explicit provides just some kind of short term reproducibility.

For example, if you use packages from non-standard channels, the owner could delete them at any moment. Also, the resolved URLs could vary due to changes in package labels or storage.

There is an ongoing debate about how to unify the different available tools to solve this problem.

In this workflow, I propose a simple but effective way to keep your environments reproducible using GitHub Actions and conda-pack:

Every time you publish a new release of your code (e.g. a paper) on GitHub, the environment is solved, packed and uploaded as an asset.

Submission Category:

DIY Deployments

Yaml File or Link to Code

epassaro / repro-conda-envs

An example repository on how to keep Anaconda environments reproducible in the long term with GitHub Actions

repro-conda-envs

An example repository on how to keep Anaconda environments reproducible in the long term with GitHub Actions

View on GitHub

Additional Resources / Info

Keep your research reproducible with conda-pack and GitHub Actions

epassaro ・ Nov 27 '21

#actionshackathon21 #research #science

Caching Anaconda environments on GitHub Actions

epassaro — Wed, 24 Nov 2021 15:03:39 +0000

My Workflow

One of the most time-consuming tasks on my workflows is the solving, download and installation of Anaconda environments. In some cases, just solving the dependencies can take up to 10 minutes depending on the platform you are building on.

This workflow aims to save time and computational resources by caching deployed Anaconda environments using the actions/cache task and the conda-incubator/setup-miniconda action.

Shorter build times and better resource management will benefit not just your organization but also the environment.

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

epassaro / cache-conda-envs

Speed up your builds by caching Anaconda environments on GitHub Actions

cache-conda-envs 🐍 ⚡

Speed up your builds by caching Anaconda environments on GitHub Actions

View on GitHub

Additional Resources / Info

I'm glad to say that the results of my work have been recently added to the conda-incubator/setup-miniconda action's documentation and should reach more developers soon.

It's worth mentioning that the documentation of actions/cache included examples for many package managers, but not for conda. On the other hand, the setup-miniconda documentation described a way to cache the downloaded packages, but that method makes pipelines even slower.

Finally, I published a post describing the workflow step-by-step.

Reduce your build times on GitHub Actions by caching Anaconda environments

epassaro ・ Nov 8 '21

#actionshackathon21 #devops

Measure docstring coverage of Python packages with GitHub Actions

epassaro — Fri, 19 Nov 2021 04:42:41 +0000

My Workflow

Workflows that enforce code style and coverage are widely used on GitHub, but... what about code documentation?

This workflow does the job by using the docstr-coverage package.

Fails when the docstring coverage is lower than the score of the base branch (on pull requests) or the previous commit (on push). Files that made the job fail are blamed.
Pushing changes to the main branch updates the current coverage of the project by creating a dynamic badge with through the shields.io endpoint.
It is possible to define the range of the badge color based on the coverage results.

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

epassaro / docstr-cov-workflow

Measure docstring coverage of Python packages with GitHub Actions

docstr-cov-workflow

Measure docstring coverage of Python packages with GitHub Actions

Usage

Copy .github/workflows/docstr-cov.yml and .docstr.yaml to your repository.
Tweak the configuration file following the package documentation.
Login to https://jsonbin.org and store the API key as a repository secret named JSONBIN_APIKEY.
The workflow will fail if the coverage is lower than the score of the base branch (on pull_request) or the previous commit (on push), and files that made the job fail will be blamed.
Pushing to main branch updates the current coverage of the project by updating a nice badge.
You can change the color range of the badge by tweaking the RANGE variable at the top of the workflow. For example, 50..75 means that coverage below 50 will display a red badge, and above 75 a green one.
Remember to add the badge to your README.md

Example

Make changes to example/base.py and see the workflow…

View on GitHub

Additional Resources / Info

An older version of this workflow is currently used by TARDIS-SN, a Montecarlo radiative transfer code that creates synthetic spectra for supernovae.

How to keep track of docstring coverage of Python packages on CI

epassaro ・ Nov 19 '21

#actionshackathon21 #python

How to keep track of docstring coverage of Python packages on CI

epassaro — Fri, 19 Nov 2021 04:13:11 +0000

Months ago, a collaborator asked for a way to keep track of the docstring coverage of our Python package. We wanted to measure the current coverage of the docstrings in our code and prevent pull requests from decreasing that value.

To solve this problem, a workflow needed to fulfill the following requirements:

The workflow should fail if the coverage is lower than the score of the base branch (on pull requests) or the previous commit (on push), and files that made the job fail should be blamed.
Pushing to main branch should update the current coverage of the project and display the result on a nice badge.

Then, I found the excellent docstr-coverage package that suited most of our needs, and in combination with GitHub Actions, shields.io and jsonbin.org I came up with a solution.

jsonbin

jsonbin.org is a personal key/value JSON store as a service.

In this case, we use this service to create dynamic badges with the shields.io endpoint. A small JSON dictionary is passed to the endpoint and the badge is created on-the-go. Thus, we avoid to push a new badge to the repository each time the coverage changes.

{
  "schemaVersion": 1,
  "label": "docstr-cov",
  "message": "75%",
  "color": "green"
}

You will need to sign in to jsonbin with your GitHub account and store the token as a repository secret named JSONBIN_APIKEY.

Configuration file

Place a file named .docstr.yml at the root of your repository.

paths:
  - your_package
verbose: 2 # int (0-3)
skip_magic: True
skip_file_doc: True
skip_init: True
skip_class_def: False
skip_private: True
follow_links: True
percentage_only: False

For more information, see the package documentation.

The workflow

This workflow should work out the box. It's not necessary to tweak any environment variable, but you can choose different values for RANGE.

For example, a RANGE of 50..75 means that coverage below 50 will display a red badge, and above 75 a green one. It works exactly like Codecov!

name: docstr-cov

on:
  push:
    branches:
    - main

  pull_request:
    branches:
    - main

env:
  RANGE: 50..75
  ENDPOINT: https://jsonbin.org/${{ github.repository_owner }}/${{ github.event.repository.name }}
  TOKEN: ${{ secrets.JSONBIN_APIKEY }}

At the job level, the steps are easy to follow:

Commits to compare (HEAD and BASE) are chosen depending on the event trigger: HEAD of the branch vs. previous commit on push events, or HEAD of the PR vs. base of the branch on pull_request.
Get coverage score on BASE and HEAD. Fails if HEAD score is lower.
Blame files (if failed).

jobs:
  check:
    runs-on: ubuntu-latest
    steps:

      - uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Setup Python
        uses: actions/setup-python@v2
        with:
          python-version: 3.x

      - name: Install docstr-coverage
        run: pip install docstr-coverage

      - name: Get SHAs
        run: |
          if [[ ${{ github.event_name }} == 'push' ]]; then
            echo "BASE=$(git rev-parse HEAD^)" >> $GITHUB_ENV
            echo "HEAD=$(git rev-parse HEAD)" >> $GITHUB_ENV

          elif [[ ${{ github.event_name }} == 'pull_request' ]]; then
            echo "BASE=${{ github.event.pull_request.base.sha }}" >> $GITHUB_ENV
            echo "HEAD=${{ github.event.pull_request.head.sha }}" >> $GITHUB_ENV

          else
            echo "Unexpected event trigger"
            exit 1
          fi

      - name: Get base coverage
        run: |
          git checkout $BASE
          echo "BASE_COV=$(docstr-coverage -p)" >> $GITHUB_ENV

      - name: Test head coverage
        run: |
          git checkout $HEAD
          docstr-coverage --fail-under=$BASE_COV

      - name: Blame
        run: |
          git diff --name-only $(git merge-base $BASE $HEAD) | \
          xargs docstr-coverage --accept-empty
        if: failure()

Only on push events:

Get coverage (rounded)
Set the color label according to RANGE.
Post results to jsonbin.
Make the endpoint public.
Print the badge URL.

      - name: Get new coverage
        run: echo "NEW_COV=$(printf "%.f" $(docstr-coverage -p))" >> $GITHUB_ENV
        if: always() && github.event_name == 'push'

      - name: Set label color
        run: |
          if [[ $NEW_COV -ge $(echo {${{ env.RANGE }}} | awk '{print $NF;}') ]]; then
            echo "COLOR=green" >> $GITHUB_ENV
          elif [[ $NEW_COV -lt $(echo {${{ env.RANGE }}} | awk '{print $1;}') ]]; then
            echo "COLOR=red" >> $GITHUB_ENV
          else
            echo "COLOR=orange" >> $GITHUB_ENV
          fi
        if: always() && github.event_name == 'push'

      - name: Post results
        run: |
          curl -X POST $ENDPOINT/badges/docstr-cov \
          -H "authorization: token $TOKEN" \
          -d "{ \"schemaVersion\": 1, \"label\": \"docstr-cov\", \
                \"message\": \"$NEW_COV%\", \"color\": \"$COLOR\" }"
        if: always() && github.event_name == 'push'

      - name: Set public endpoint
        run: |
          curl -X PUT $ENDPOINT/_perms -H "authorization: token $TOKEN"
        if: always() && github.event_name == 'push'

      - name: Show badge URL
        run: echo "https://img.shields.io/endpoint?url=$ENDPOINT/badges/docstr-cov"
        if: always() && github.event_name == 'push'

The badge should be updated dynamically on every push to main. Remember to add it to your README.md.

Get the code

epassaro / docstr-cov-workflow

Measure docstring coverage of Python packages with GitHub Actions

docstr-cov-workflow

Measure docstring coverage of Python packages with GitHub Actions

Usage

Copy .github/workflows/docstr-cov.yml and .docstr.yaml to your repository.
Tweak the configuration file following the package documentation.
Login to https://jsonbin.org and store the API key as a repository secret named JSONBIN_APIKEY.
The workflow will fail if the coverage is lower than the score of the base branch (on pull_request) or the previous commit (on push), and files that made the job fail will be blamed.
Pushing to main branch updates the current coverage of the project by updating a nice badge.
You can change the color range of the badge by tweaking the RANGE variable at the top of the workflow. For example, 50..75 means that coverage below 50 will display a red badge, and above 75 a green one.
Remember to add the badge to your README.md

Example

Make changes to example/base.py and see the workflow…

View on GitHub

A RTD-like documentation pipeline for GitHub Actions

epassaro — Mon, 15 Nov 2021 16:14:23 +0000

My Workflow

In the recent years, lot of Python packages moved their documentation pipelines from third party services like ReadTheDocs to GitHub Pages, but some useful features were missing in the process.

This workflow intends to be a full featured replacement for RTD on GitHub Actions, giving back the control of the documentation deployment process to developers.

Features:

Support of pip and conda dependency files.
Build and deploy branches under /branches/<branch>.
Build and deploy tags under /tags/<tag>
Secure build and preview of pull requests under /pull/<number> via labels.
Manual trigger for branches.
Select branch to deploy the site (default: gh-pages).
Redirect the main domain to /latest or /stable (default: /latest).
Redirect the /stable subdomain to the latest SemVer tag, or the stable branch (if exists).
Automatic removal of pages from closed/merged pull requests, and deleted branches or tags.

Not supported:

Multi-language builds.

Live demo:

Submission Category:

DIY Deployments

Yaml File or Link to Code

epassaro / actions-rtd-workflow

A RTD-like documentation pipeline for GitHub Actions

actions-rtd-workflow

A RTD-like documentation pipeline for GitHub Actions

Features

Support of pip and conda dependency files.
Build and deploy branches under /branches/<branch>.
Build and deploy tags under /tags/<tag>.
Secure build and preview of pull requests under /pull/<number> via labels.
Manual trigger for branches.
Select branch to deploy the site (default: gh-pages).
Redirect the main domain to /latest or /stable (default: /latest).
Redirect the /stable subdomain to the latest SemVer tag, or the stable branch (if exists).
Automatic removal of pages from closed/merged pull requests, and deleted branches or tags.

Not supported

Multi-language builds.

Live demo

View on GitHub

Additional Resources / Info

Deploy your package documentation on GitHub Pages in the RTD style: preview PRs, and more!

epassaro ・ Nov 15 '21

#actionshackathon21 #github