Repository navigation
Draft v1 #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.
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
Draft v1 #1
Changes from all commits
0415edd
5abf569
5c22b33
7c6bcbf
2a51044
58a0d28
4097deb
f3eccbc
4a958bf
b5f71dc
577ae1d
19cc932
8a017f2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| name: "CodeQL" | ||
|
|
||
| on: [pull_request] | ||
| jobs: | ||
| lint: | ||
| name: CodeQL | ||
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v3 | ||
| with: | ||
| fetch-depth: 2 | ||
|
|
||
| - run: git checkout HEAD^2 | ||
|
|
||
| - name: Run CodeQL | ||
| run: | | ||
| docker run --rm -v $PWD:/app composer:2.6 sh -c \ | ||
| "composer install --profile --ignore-platform-reqs && composer check" | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| name: "Linter" | ||
|
|
||
| on: | ||
| pull_request: | ||
| push: | ||
| branches: [ main ] | ||
| workflow_dispatch: | ||
|
|
||
| jobs: | ||
| lint: | ||
| name: Linter | ||
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 2 | ||
|
|
||
| # Platform requirements are enforced here as they are in the image the | ||
| # tests run in: a dependency that could not run on a supported PHP should | ||
| # fail the job rather than install and be linted anyway. | ||
| - name: Run Linter | ||
| run: | | ||
| docker run --rm -v $PWD:/app composer:2 sh -c \ | ||
| "composer install --profile && composer lint" |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,49 @@ | ||
| name: "Tests" | ||
|
|
||
| on: | ||
| pull_request: | ||
| push: | ||
| branches: [ main ] | ||
| workflow_dispatch: | ||
|
|
||
| jobs: | ||
| tests: | ||
| name: Tests | ||
| runs-on: ubuntu-latest | ||
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| php-versions: [ '8.2', '8.3', '8.4' ] | ||
|
|
||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 2 | ||
|
|
||
| - name: Build | ||
| run: | | ||
| export PHP_VERSION=${{ matrix.php-versions }} | ||
| docker compose build | ||
| docker compose up -d | ||
|
|
||
| # The container is ready when PHP and both binaries answer, which is a | ||
| # question worth asking rather than a wait worth guessing at. | ||
| - name: Wait for the container | ||
| run: | | ||
| for attempt in $(seq 1 30); do | ||
| if docker compose exec -T tests sh -c 'php -v && ffmpeg -version && ffprobe -version' >/dev/null 2>&1; then | ||
| echo "ready after ${attempt}s" | ||
| exit 0 | ||
| fi | ||
| sleep 1 | ||
| done | ||
| echo "the test container never became ready" | ||
| docker compose logs | ||
| exit 1 | ||
|
|
||
| - name: Run Unit Tests | ||
| run: docker compose exec -T tests vendor/bin/phpunit --configuration phpunit.xml --testsuite unit | ||
|
|
||
| - name: Run E2E Tests | ||
| run: docker compose exec -T tests vendor/bin/phpunit --configuration phpunit.xml --testsuite e2e |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| /vendor/ | ||
| .phpunit* | ||
| .phpunit.cache | ||
| .idea | ||
| .DS_Store |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,76 @@ | ||
| # Contributor Covenant Code of Conduct | ||
|
|
||
| ## Our Pledge | ||
|
|
||
| In the interest of fostering an open and welcoming environment, we as | ||
| contributors and maintainers pledge to make participation in our project and | ||
| our community a harassment-free experience for everyone, regardless of age, body | ||
| size, disability, ethnicity, sex characteristics, gender identity, expression, | ||
| level of experience, education, socio-economic status, nationality, personal | ||
| appearance, race, religion, or sexual identity and orientation. | ||
|
|
||
| ## Our Standards | ||
|
|
||
| Examples of behavior that contributes to creating a positive environment | ||
| include: | ||
|
|
||
| * Using welcoming and inclusive language | ||
| * Being respectful of differing viewpoints and experiences | ||
| * Gracefully accepting constructive criticism | ||
| * Focusing on what is best for the community | ||
| * Showing empathy towards other community members | ||
|
|
||
| Examples of unacceptable behavior by participants include: | ||
|
|
||
| * The use of sexualized language or imagery and unwelcome sexual attention or | ||
| advances | ||
| * Trolling, insulting/derogatory comments, and personal or political attacks | ||
| * Public or private harassment | ||
| * Publishing others' private information, such as a physical or electronic | ||
| address, without explicit permission | ||
| * Other conduct which could reasonably be considered inappropriate in a | ||
| professional setting | ||
|
|
||
| ## Our Responsibilities | ||
|
|
||
| Project maintainers are responsible for clarifying the standards of acceptable | ||
| behavior and are expected to take appropriate and fair corrective action in | ||
| response to any instances of unacceptable behavior. | ||
|
|
||
| Project maintainers have the right and responsibility to remove, edit, or | ||
| reject comments, commits, code, wiki edits, issues, and other contributions | ||
| that are not aligned to this Code of Conduct, or to ban temporarily or | ||
| permanently any contributor for other behaviors that they deem inappropriate, | ||
| threatening, offensive, or harmful. | ||
|
|
||
| ## Scope | ||
|
|
||
| This Code of Conduct applies both within project spaces and in public spaces | ||
| when an individual is representing the project or its community. Examples of | ||
| representing a project or community include using an official project e-mail | ||
| address, posting via an official social media account, or acting as an appointed | ||
| representative at an online or offline event. Representation of a project may be | ||
| further defined and clarified by project maintainers. | ||
|
|
||
| ## Enforcement | ||
|
|
||
| Instances of abusive, harassing, or otherwise unacceptable behavior may be | ||
| reported by contacting the project team at team@appwrite.io. All | ||
| complaints will be reviewed and investigated and will result in a response that | ||
| is deemed necessary and appropriate to the circumstances. The project team is | ||
| obligated to maintain confidentiality with regard to the reporter of an incident. | ||
| Further details of specific enforcement policies may be posted separately. | ||
|
|
||
| Project maintainers who do not follow or enforce the Code of Conduct in good | ||
| faith may face temporary or permanent repercussions as determined by other | ||
| members of the project's leadership. | ||
|
|
||
| ## Attribution | ||
|
|
||
| This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, | ||
| available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html | ||
|
|
||
| [homepage]: https://www.contributor-covenant.org | ||
|
|
||
| For answers to common questions about this code of conduct, see | ||
| https://www.contributor-covenant.org/faq |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,101 @@ | ||
| # Contributing | ||
|
|
||
| We would ❤️ for you to contribute to Utopia-php and help make it better! We want contributing to Utopia-php to be fun, enjoyable, and educational for anyone and everyone. All contributions are welcome, including issues, new docs as well as updates and tweaks, blog posts, workshops, and more. | ||
|
|
||
| ## How to Start? | ||
|
|
||
| If you are worried or don’t know where to start, check out our next section explaining what kind of help we could use and where can you get involved. You can reach out with questions to [Eldad Fux (@eldadfux)](https://twitter.com/eldadfux) or anyone from the [Appwrite team on Discord](https://discord.gg/GSeTUeA). You can also submit an issue, and a maintainer can guide you! | ||
|
|
||
| ## Code of Conduct | ||
|
|
||
| Help us keep Utopia-php open and inclusive. Please read and follow our [Code of Conduct](CODE_OF_CONDUCT.md). | ||
|
|
||
| ## Submit a Pull Request 🚀 | ||
|
|
||
| Branch naming convention is as following | ||
|
|
||
| `TYPE-ISSUE_ID-DESCRIPTION` | ||
|
|
||
| example: | ||
|
|
||
| ``` | ||
| doc-548-submit-a-pull-request-section-to-contribution-guide | ||
| ``` | ||
|
|
||
| When `TYPE` can be: | ||
|
|
||
| - **feat** - is a new feature | ||
| - **doc** - documentation only changes | ||
| - **cicd** - changes related to CI/CD system | ||
| - **fix** - a bug fix | ||
| - **refactor** - code change that neither fixes a bug nor adds a feature | ||
|
|
||
| **All PRs must include a commit message with the changes description!** | ||
|
|
||
| For the initial start, fork the project and use git clone command to download the repository to your computer. A standard procedure for working on an issue would be to: | ||
|
|
||
| 1. `git pull`, before creating a new branch, pull the changes from upstream. Your `main` needs to be up to date. | ||
|
|
||
| ``` | ||
| $ git pull | ||
| ``` | ||
|
|
||
| 2. Create new branch from `main` like: `doc-548-submit-a-pull-request-section-to-contribution-guide`<br/> | ||
|
|
||
| ``` | ||
| $ git checkout -b [name_of_your_new_branch] | ||
| ``` | ||
|
|
||
| 3. Work - commit - repeat ( be sure to be in your branch ) | ||
|
|
||
| 4. Push changes to GitHub | ||
|
|
||
| ``` | ||
| $ git push origin [name_of_your_new_branch] | ||
| ``` | ||
|
|
||
| 5. Submit your changes for review | ||
| If you go to your repository on GitHub, you'll see a `Compare & pull request` button. Click on that button. | ||
| 6. Start a Pull Request | ||
| Now submit the pull request and click on `Create pull request`. | ||
| 7. Get a code review approval/reject | ||
| 8. After approval, merge your PR | ||
| 9. GitHub will automatically delete the branch after the merge is done. (they can still be restored). | ||
|
|
||
| ## Introducing New Features | ||
|
|
||
| We would 💖 you to contribute to Utopia-php, but we would also like to make sure Utopia-php is as great as possible and loyal to its vision and mission statement 🙏. | ||
|
|
||
| For us to find the right balance, please open an issue explaining your ideas before introducing a new pull request. | ||
|
|
||
| This will allow the Utopia-php community to have sufficient discussion about the new feature value and how it fits in the product roadmap and vision. | ||
|
|
||
| This is also important for the Utopia-php lead developers to be able to give technical input and different emphasis regarding the feature design and architecture. Some bigger features might need to go through our [RFC process](https://github.com/appwrite/rfc). | ||
|
|
||
| ## Other Ways to Help | ||
|
|
||
| Pull requests are great, but there are many other areas where you can help Utopia-php. | ||
|
|
||
| ### Blogging & Speaking | ||
|
|
||
| Blogging, speaking about, or creating tutorials about one of Utopia-php’s many features is great way to contribute and help our project grow. | ||
|
|
||
| ### Presenting at Meetups | ||
|
|
||
| Presenting at meetups and conferences about your Utopia-php projects. Your unique challenges and successes in building things with Utopia-php can provide great speaking material. We’d love to review your talk abstract/CFP, so get in touch with us if you’d like some help! | ||
|
|
||
| ### Sending Feedbacks & Reporting Bugs | ||
|
|
||
| Sending feedback is a great way for us to understand your different use cases of Utopia-php better. If you had any issues, bugs, or want to share about your experience, feel free to do so on our GitHub issues page or at our [Discord channel](https://discord.gg/GSeTUeA). | ||
|
|
||
| ### Submitting New Ideas | ||
|
|
||
| If you think Utopia-php could use a new feature, please open an issue on our GitHub repository, stating as much information as you can think about your new idea and it's implications. We would also use this issue to gather more information, get more feedback from the community, and have a proper discussion about the new feature. | ||
|
|
||
| ### Improving Documentation | ||
|
|
||
| Submitting documentation updates, enhancements, designs, or bug fixes. Spelling or grammar fixes will be very much appreciated. | ||
|
|
||
| ### Helping Someone | ||
|
|
||
| Searching for Utopia-php, GitHub or StackOverflow and helping someone else who needs help. You can also help by teaching others how to contribute to Utopia-php's repo! |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,110 @@ | ||
| ARG FFMPEG_VERSION=8.1.2 | ||
| ARG PHP_VERSION=8.2 | ||
| ARG SWOOLE_VERSION=v6.2.2 | ||
|
|
||
| FROM php:${PHP_VERSION}-cli-alpine AS ffmpeg | ||
|
|
||
| ARG FFMPEG_VERSION | ||
|
|
||
| RUN apk add --no-cache \ | ||
| build-base nasm pkgconf curl xz \ | ||
| x264-dev x265-dev libvpx-dev opus-dev lame-dev zlib-dev \ | ||
| libtheora-dev libvorbis-dev | ||
|
|
||
| RUN curl -fsSL "https://ffmpeg.org/releases/ffmpeg-${FFMPEG_VERSION}.tar.xz" | tar -xJ -C /tmp \ | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The image compiles a version-addressed FFmpeg archive and a mutable Swoole Git ref without checking a digest, signature, or resolved commit, so substituted upstream content would execute during the build and be incorporated into the final image. Pin and verify immutable content identities for both sources. How this was verified: Both remote sources flow directly into root-run build commands, and their resulting binaries are copied into the final image without an intervening integrity check. Prompt To Fix With AIThis is a comment left during a code review.
Path: Dockerfile
Line: 14
Comment:
**Unverified build source artifacts**
The image compiles a version-addressed FFmpeg archive and a mutable Swoole Git ref without checking a digest, signature, or resolved commit, so substituted upstream content would execute during the build and be incorporated into the final image. Pin and verify immutable content identities for both sources.
**How this was verified:** Both remote sources flow directly into root-run build commands, and their resulting binaries are copied into the final image without an intervening integrity check.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly. |
||
| && cd "/tmp/ffmpeg-${FFMPEG_VERSION}" \ | ||
| && ./configure \ | ||
| --prefix=/opt/ffmpeg \ | ||
| --enable-gpl \ | ||
| --enable-libx264 \ | ||
| --enable-libx265 \ | ||
| --enable-libvpx \ | ||
| --enable-libopus \ | ||
| --enable-libmp3lame \ | ||
| --enable-libtheora \ | ||
| --enable-libvorbis \ | ||
| --disable-debug \ | ||
| --disable-doc \ | ||
| --disable-ffplay \ | ||
| && make -j"$(nproc)" \ | ||
| && make install \ | ||
| && /opt/ffmpeg/bin/ffmpeg -version \ | ||
| && rm -rf "/tmp/ffmpeg-${FFMPEG_VERSION}" | ||
|
|
||
| # Built from source, pinned, in its own stage so it compiles alongside ffmpeg | ||
| # rather than after it. Only the tests need it: the library itself has no swoole | ||
| # dependency, it just has to keep yielding when a caller runs it in a coroutine, | ||
| # and that is only provable with the real scheduler. | ||
| FROM php:${PHP_VERSION}-cli-alpine AS swoole | ||
|
|
||
| ARG SWOOLE_VERSION | ||
|
|
||
| RUN apk add --no-cache \ | ||
| build-base autoconf openssl-dev linux-headers git file \ | ||
| && git clone --depth 1 --branch "${SWOOLE_VERSION}" https://github.com/swoole/swoole-src.git /tmp/swoole \ | ||
| && cd /tmp/swoole \ | ||
| && phpize \ | ||
| && ./configure \ | ||
| && make -j"$(nproc)" \ | ||
| && make install \ | ||
| && mkdir -p /ext \ | ||
| && cp "$(php-config --extension-dir)/swoole.so" /ext/swoole.so \ | ||
| && rm -rf /tmp/swoole | ||
|
|
||
| FROM composer:2 AS vendor | ||
|
|
||
| ARG TESTING=false | ||
|
|
||
| WORKDIR /usr/local/src/ | ||
|
|
||
| COPY composer.json composer.lock /usr/local/src/ | ||
|
|
||
| # No --ignore-platform-reqs: the lock is resolved against the oldest supported | ||
| # PHP, so anything that would not run in this image should fail the build rather | ||
| # than install and break at runtime. | ||
| RUN composer install --optimize-autoloader \ | ||
| --no-plugins --no-scripts --prefer-dist \ | ||
| $(test "$TESTING" = "true" || echo "--no-dev") | ||
|
|
||
| FROM php:${PHP_VERSION}-cli-alpine AS final | ||
|
|
||
| LABEL maintainer="team@appwrite.io" | ||
|
|
||
| ENV TZ=UTC | ||
|
|
||
| RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone | ||
|
|
||
| RUN apk add --no-cache \ | ||
| x264-libs x265-libs libvpx opus lame-libs libtheora libvorbis libstdc++ | ||
|
|
||
| COPY --from=ffmpeg /opt/ffmpeg/bin/ffmpeg /opt/ffmpeg/bin/ffprobe /usr/local/bin/ | ||
|
|
||
| COPY --from=swoole /ext/swoole.so /ext/swoole.so | ||
|
|
||
| RUN cp /ext/swoole.so "$(php-config --extension-dir)/" \ | ||
| && echo extension=swoole.so > /usr/local/etc/php/conf.d/swoole.ini \ | ||
| && rm -rf /ext | ||
|
|
||
| # Enough headroom for a cold phpstan run, which needs more than the 128M default. | ||
| RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini" \ | ||
| && echo "memory_limit=1024M" >> "$PHP_INI_DIR/php.ini" | ||
|
|
||
| WORKDIR /usr/src/code | ||
|
|
||
| COPY --from=vendor /usr/local/src/vendor /usr/src/code/vendor | ||
|
|
||
| # Add Source Code | ||
| COPY ./src /usr/src/code/src | ||
| COPY ./tests /usr/src/code/tests | ||
| COPY ./composer.json /usr/src/code/composer.json | ||
| COPY ./phpunit.xml /usr/src/code/phpunit.xml | ||
| COPY ./phpstan.neon /usr/src/code/phpstan.neon | ||
| COPY ./pint.json /usr/src/code/pint.json | ||
|
|
||
| # Asserted rather than printed: without this the coroutine suite would go back to | ||
| # skipping itself, and a skipped test is quiet about being absent. | ||
| RUN ffmpeg -version && ffprobe -version \ | ||
| && php --ri swoole > /dev/null \ | ||
| && php -r 'exit(extension_loaded("swoole") ? 0 : 1);' | ||
|
|
||
| CMD [ "tail", "-f", "/dev/null" ] | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When the end-to-end suite runs through the provided Compose service, the container executes as root and Prompt To Fix With AIThis is a comment left during a code review.
Path: Dockerfile
Line: 110
Comment:
**Root-owned bind-mount artifacts**
When the end-to-end suite runs through the provided Compose service, the container executes as root and `Samples::build()` writes into the bind-mounted `tests/samples` directory, leaving host files that ordinary users cannot modify or clean up without elevated privileges.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The checkout action is referenced by mutable major-version tags here and in the linter and test workflows, allowing a repointed tag to execute unexpected code with access to the CI workspace and available workflow credentials. Pin each action to a full immutable commit SHA.
How this was verified: All three new workflows reference
actions/checkoutthroughv3orv4tags rather than commit SHAs.Prompt To Fix With AI