Giter Club home page Giter Club logo

.github's Introduction

logo

BeeWare

Python Versions PyPI Version Maturity BSD License Build Status Discord server

BeeWare is a collection of tools and libraries for building and distributing native applications in Python.

For an introduction to the full BeeWare suite, we recommend running the BeeWare Tutorial.

Community

You can talk to the BeeWare community through:

We foster a welcoming and respectful community as described in our BeeWare Community Code of Conduct.

Contributing

If you experience problems with BeeWare, log them on GitHub. If you want to contribute code, please fork the code and submit a pull request.

Translations

Translation status

We manage translations using Weblate.

Translation status

If you'd like to contribute to the translation effort, join the #translations channel on Discord and introduce yourself!

.github's People

Contributors

astraluma avatar brutusthebee avatar dependabot[bot] avatar freakboy3742 avatar rmartin16 avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

.github's Issues

Skip RTD checks in CI when PR comes from outside the organization

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.

Make `beeware-ci` package public

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

Upgrade to `actions/[email protected]` and `actions/[email protected]`

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:

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

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.

Dependency updates failing

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

Cache Docker images for `app-build-verify`

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...

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.