beeware / .github Goto Github PK

Describe the bug

When a PR to this repo is submitted from outside the organisation (eg, a dependbot update), CI tasks checking RTD will fail.

Steps to reproduce

Submit a PR from a non-BeeWare repo. CI will fail the "Verify Docs Build (briefcase)" and "Verify Docs Build (toga)" tasks.

Expected behavior

CI should pass green, with the RTD tests being skipped.

Screenshots

No response

Environment

• Operating System: CI

Logs

See https://github.com/beeware/.github/actions/runs/9538701504/job/26288364901?pr=144

Run echo "Verifying docs for v0.3.13 were successfully built:"
  echo "Verifying docs for v0.3.13 were successfully built:"
  while true
  do
      RTD_RESPONSE=$(curl -s -H "Authorization: Token " "${RTD_API_URL}")
      IS_DOCS_BUILT=$(jq .built <<< ${RTD_RESPONSE})
  
      echo "::group::IS_DOCS_BUILT=${IS_DOCS_BUILT}"
      jq <<< ${RTD_RESPONSE}
      echo "::endgroup::"
  
      if [[ "${IS_DOCS_BUILT}" == "true" ]]; then
          exit 0
      fi
  
      sleep 5
  done
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    RTD_API_URL: https://readthedocs.org/api/v3/projects/briefcase/versions/v0.3.13/
Verifying docs for v0.3.13 were successfully built:
IS_DOCS_BUILT=null
  {
    "detail": "Invalid token header. No credentials provided."
  }

...

IS_DOCS_BUILT=null
  {
    "detail": "Invalid token header. No credentials provided."
  }
Error: The operation was canceled.

Additional context

The problem appears to be that the job requires an API token, but that API token isn't exposed to external PRs.

In practice, this isn't an issue, as PRs from BeeWare (such as the autoupdate script) and use in downstream repos (where it is part of the release workflows) will always have access to the token. This is purely an inconvenience for evaluating PRs submitted to this repo - and even then, only dependabot PRs.

We either need to skip these tests if the submitting repository isn't beeware; or switch to a mechanism of evaluating a build that doesn't require an API token (e.g., a direct inspection of the expected published page, looking for a 404?)

This isn't a new problem has existed for a while; it's easy enough to work around, but I figured if someone has some spare time, it would be a nice bit of polish to fix it.

Describe the bug

The caching package beeware-ci introduced via #99 needs to be public; it is currently private.

As a private package, only blessed GITHUB_TOKENs are allowed access as made evident by CI for beeware/briefcase#1666.

Steps to reproduce

Run CI for a PR from a non-beeware org member.

Expected behavior

Caching image is available and pulled for CI runs.

Screenshots

No response

Environment

CI

Logs

No response

Additional context

No response

What is the problem or limitation you are having?

The v4 releases of actions/upload-artifact and actions/download-artifact include a series of massive backwards incompatibilities:

• It is no longer possible to upload multiple artefacts with the same name
• It is no longer possible to download multiple artefacts with a wildcard (unconfirmed, but definitely not documnted)
• If you download multiple artefacts, they are now put into parallel subdirectories, instead of being merged into a single directory.

Describe the solution you'd like

Make the changes necessary to track the new releases.

Describe alternatives you've considered

• Stay on the v3 series forever. This will eventually cause bitrot, because the underlying Node version will be deprecated.
• Fork the packages...

Additional context

Github issue requesting guidance on migration

The following Dependabot PRs were created automatically, and failed CI:

• #75
• #76
• beeware/briefcase#1577
• beeware/briefcase#1578
• beeware/rubicon-objc#394
• beeware/travertino#119
• beeware/toga#2285
• beeware/toga#2286
• beeware/toga-chart#73

The following Dependabot PRs were created automatically, and passed CI:

• beeware/cpython-apple-source-deps#2
• beeware/cpython-apple-source-deps#3
• beeware/Python-Apple-support#195
• beeware/Python-Apple-support#196
• beeware/Python-support-testbed#52
• beeware/briefcase-macOS-app-template#31
• beeware/briefcase-macOS-app-template#32
• beeware/briefcase-windows-app-template#28
• beeware/briefcase-windows-app-template#29

Even though they passed CI, Dependabot was suspended for the upload/download actions. It's possible they've worked as intended; but given the size of the change, they usage needs to be carefully audited.

Describe the bug

The "Update Dependency versions" task failed on the Sunday night

It looks like running the dependency updater on .github is problematic because it doesn't have a .github checkout.

Steps to reproduce

Run the dependency update workflow on .github main.

Expected behavior

Dependency update task should complete.

Screenshots

No response

Environment

GitHub Actions.

Logs

Additional context

No response

What is the problem or limitation you are having?

Currently, CI must completely rebuild several images every time it runs. These should be cached and downloaded when needed. This should work for non-main branches as well as forks such that even a brand new fork will use a cached image.

Describe the solution you'd like

Like anything worth doing in Docker, this ain't easy.

Independent of the Docker image build process, you can't just say "take the current state, cache it, and let me restore it when I try to build again"...everything is a bit more tightly integrated. The is primarily because the "state" isn't just the tag assigned at the end; you can't just export that image for that tag, save it somewhere, re-import it later, and expect the docker build command to know it doesn't need to redo everything. That image needs additional metadata and potentially even additional layers that wouldn't be normally included for docker build to treat it more like a cache.

But even then, the docker build command needs to be instructed to use it; therefore, the docker build command from Briefcase will almost certainly need to be updated to support arbitrary additional options.

This Docker caching is facilitated via the --cache-to and --cache-from options.

Option 1: Inline Caching

The simplest way to accomplish this may be "inline" caching. When this is configured, Docker treats the output image as the place to cache. So, if you push an image to a registry built with inline caching and pull it later, your docker build command can use it.

However, the Briefcase images aren't currently tagged in a way for them to be pushed to a registry....so, there will need to be this dance of associating another tag with the image and then pushing. Conversely, when they are pulled down, they'll need to be re-tagged again.

Option 2: Direct Registry Caching

Docker supports caching to and from a registry directly....however, they don't support this out of the box for a reason I haven't grasped yet. So, a custom builder needs to be created using the "docker-container" driver.

In this way, the --cache-to and --cache-from options simply need to set to an arbitrary registry image that Docker will treat as a cache.....it's actually pretty snazzy.....but I don't understand the potential consequences of creating and using such a builder with Briefcase yet.

Describe alternatives you've considered

No caching.

Additional context

This will serve as a knowledge dump for now....since I realized I won't be able to knock this out very quickly apparently...