Skip to content

Gaq2 #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Sir-Ripley merged 2 commits into from
Nov 29, 2025
Merged

Gaq2 #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5f1587d
Add SLSA generic generator workflow
Sir-Ripley Nov 28, 2025
39845e7
Add GitHub Actions workflow for Jekyll site CI
Sir-Ripley Nov 28, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions .github/workflows/generator-generic-ossf-slsa3-publish.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.

# This workflow lets you generate SLSA provenance file for your project.
# The generation satisfies level 3 for the provenance requirements - see https://slsa.dev/spec/v0.1/requirements
# The project is an initiative of the OpenSSF (openssf.org) and is developed at
# https://github.com/slsa-framework/slsa-github-generator.
# The provenance file can be verified using https://github.com/slsa-framework/slsa-verifier.
# For more information about SLSA and how it improves the supply-chain, visit slsa.dev.

name: SLSA generic generator
on:
workflow_dispatch:
release:
types: [created]

jobs:
build:
runs-on: ubuntu-latest
outputs:
digests: ${{ steps.hash.outputs.digests }}

steps:
- uses: actions/checkout@v4

# ========================================================
#
# Step 1: Build your artifacts.
#
# ========================================================
- name: Build artifacts
run: |
# These are some amazing artifacts.
echo "artifact1" > artifact1
echo "artifact2" > artifact2
# ========================================================
#
# Step 2: Add a step to generate the provenance subjects
# as shown below. Update the sha256 sum arguments
# to include all binaries that you generate
# provenance for.
#
# ========================================================
- name: Generate subject for provenance
id: hash
run: |
set -euo pipefail
# List the artifacts the provenance will refer to.
files=$(ls artifact*)
# Generate the subjects (base64 encoded).
echo "hashes=$(sha256sum $files | base64 -w0)" >> "${GITHUB_OUTPUT}"
provenance:
needs: [build]
permissions:
actions: read # To read the workflow path.
id-token: write # To sign the provenance.
contents: write # To add assets to a release.
uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.4.0
with:
base64-subjects: "${{ needs.build.outputs.digests }}"
upload-assets: true # Optional: Upload to a new release
20 changes: 20 additions & 0 deletions .github/workflows/jekyll-docker.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
name: Jekyll site CI

on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]

jobs:
build:

runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v4
- name: Build the site in the jekyll/builder container
run: |
docker run \
-v ${{ github.workspace }}:/srv/jekyll -v ${{ github.workspace }}/_site:/srv/jekyll/_site \
jekyll/builder:latest /bin/bash -c "chmod -R 777 /srv/jekyll && jekyll build --future"
Copy link

@sourcery-ai sourcery-ai bot Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚨 suggestion (security): Using chmod -R 777 inside the container is overly permissive and may mask permission issues.

Within the container, this also lets any process modify the build inputs/outputs under /srv/jekyll, which is broader than necessary.

Consider instead:

  • Matching ownership/permissions to the Jekyll user/group (e.g. chown -R jekyll:jekyll /srv/jekyll plus a more restrictive chmod like 755), or
  • Configuring docker run (e.g. --user or mount options) so a blanket recursive 777 isn’t needed.

This keeps the CI environment closer to production and makes permission issues more visible rather than papered over by 777.

Copy link
Owner Author

@Sir-Ripley Sir-Ripley Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you either correct this and do this for me, or give me a step-by-step on how to

Copy link
Owner Author

@Sir-Ripley Sir-Ripley Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you either correct this and do this for me, or give me a step-by-step on how to?

Copy link

@sourcery-ai sourcery-ai bot Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You’re right to ask for something concrete here.

I can’t directly edit the PR for you, but here’s a step‑by‑step with an updated workflow snippet you can paste in.

1. Use the Jekyll image’s default user instead of chmod 777

The jekyll/builder image already has a jekyll user configured for running the build. The main issue is that when you mount your repo from the GitHub runner into the container, the files are owned by a different UID, so the jekyll user may not have write permissions.

A cleaner pattern is:

  • Run the container as the same UID/GID as the GitHub runner user, or
  • Ensure the Jekyll user has ownership of the mounted dir (using chown), but with sane permissions instead of 777.

Given GitHub Actions runs as uid=1001 on ubuntu-latest, we can run the container as that user and avoid chmod -R 777 entirely.

2. Updated workflow snippet

Replace your current run step with something like this:

    - name: Build the site in the jekyll/builder container
      run: |
        # Detect the current user and group IDs (GitHub runner user)
        UID=$(id -u)
        GID=$(id -g)

        docker run \
          --user "$UID:$GID" \
          -v "${{ github.workspace }}:/srv/jekyll" \
          -v "${{ github.workspace }}/_site:/srv/jekyll/_site" \
          jekyll/builder:latest \
          jekyll build --future

Key changes:

  • --user "$UID:$GID" makes the container process run as the same user as the GitHub runner, so it already has appropriate permissions on the mounted files.
  • Removed the chmod -R 777 entirely.
  • Dropped the /bin/bash -c wrapper since we’re just running a single command.

3. If you prefer to keep using the jekyll user

If you’d rather rely on the jekyll user inside the image, you can instead adjust ownership once, but with more restrictive permissions:

    - name: Build the site in the jekyll/builder container
      run: |
        docker run \
          -v "${{ github.workspace }}:/srv/jekyll" \
          -v "${{ github.workspace }}/_site:/srv/jekyll/_site" \
          jekyll/builder:latest \
          /bin/bash -c "\
            chown -R jekyll:jekyll /srv/jekyll && \
            chmod -R u+rwX,go+rX /srv/jekyll && \
            jekyll build --future \
          "

Here:

  • chown -R jekyll:jekyll /srv/jekyll gives the jekyll user ownership of the source and _site directories.
  • chmod -R u+rwX,go+rX means:
    • User: read, write, execute where appropriate.
    • Group/others: read and execute only (no write).

4. What you need to do

  1. Pick one of the two snippets above (I recommend the first one with --user "$UID:$GID").
  2. Replace the existing run: block in .github/workflows/jekyll-docker.yml with that snippet.
  3. Push the change to your branch – GitHub Actions will automatically rerun the workflow on the PR.

If you paste your updated YAML here, I can sanity‑check it before you push, or we can tweak for any errors the workflow logs show.

Copy link

@sourcery-ai sourcery-ai bot Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You’re right to ask for something concrete here.

You have two options:

  1. A minimal change that just avoids 777 but keeps the pattern you’re using now.
  2. A more robust change that runs the container as your GitHub Actions user so you don’t need to chmod at all.

Below I’ll show you both, with copy‑pasteable YAML.

1) Minimal fix: more restrictive permissions

The jekyll/builder image uses a jekyll user internally. A safer pattern than chmod -R 777 is to:

  • set ownership to jekyll:jekyll, and
  • set permissions to something like u+rwX,go+rX (readable by others, but not world‑writable).

Update your workflow step to this:

- name: Build the site in the jekyll/builder container
  run: |
    docker run \
      -v ${{ github.workspace }}:/srv/jekyll \
      -v ${{ github.workspace }}/_site:/srv/jekyll/_site \
      jekyll/builder:latest /bin/bash -c "\
        chown -R jekyll:jekyll /srv/jekyll && \
        chmod -R u+rwX,go+rX /srv/jekyll && \
        jekyll build --future"

What changed:

  • Replaced chmod -R 777 with:
    • chown -R jekyll:jekyll /srv/jekyll (make the jekyll user own the files)
    • chmod -R u+rwX,go+rX /srv/jekyll (read/execute for everyone, write only for owner)

This keeps things permissive enough for the container to work but avoids world‑writable permissions.

2) Better approach: match the host user (no chmod at all)

Another option is to run the container as the same user ID that GitHub Actions uses (typically runner with UID 1001). This way, file permissions match by default and you don’t need chmod.

- name: Build the site in the jekyll/builder container
  run: |
    docker run \
      --user $(id -u):$(id -g) \
      -v ${{ github.workspace }}:/srv/jekyll \
      -v ${{ github.workspace }}/_site:/srv/jekyll/_site \
      jekyll/builder:latest jekyll build --future

What changed:

  • Added --user $(id -u):$(id -g) so the container uses the same UID/GID as the GitHub runner.
  • Removed the chmod completely.

If you try this and the build fails with a permissions error, fall back to option 1.

Which should you use?

  • If you want the least disruptive change that almost certainly works right away, use Option 1.
  • If you want the cleanest setup that avoids permission hacks, try Option 2 first and only move to option 1 if you hit issues.

If you tell me which option you’d like, I can adapt the full .github/workflows/jekyll-docker.yml for you and show the complete file as it should look.

Loading