-
Notifications
You must be signed in to change notification settings - Fork 179
Deploy workflow: never let the website step block the F-Droid push #655
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
Merged
SGI-CAPP-AT2
merged 1 commit into
CCExtractor:main
from
BrawlerXull:fix/deploy-survives-missing-website
Aug 23, 2026
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: CCExtractor/taskwarrior-flutter
Length of output: 197
🏁 Script executed:
Repository: CCExtractor/taskwarrior-flutter
Length of output: 14324
Serialize push and manual deployments.
The workflow has no concurrency group. Add a workflow-level group with
cancel-in-progress: falseto prevent concurrent runs from force-pushing conflictingfdroid-reposnapshots.🤖 Prompt for AI Agents
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: CCExtractor/taskwarrior-flutter
Length of output: 9965
🌐 Web query:
GitHub Actions workflow_dispatch selected branch workflow file github.ref github.sha workflow definition branch official documentation💡 Result:
For GitHub Actions workflows triggered by the workflow_dispatch event, the workflow file must exist on the repository's default branch for the trigger to be recognized [1][2][3]. However, once configured, you can manually trigger the workflow to run on any specific branch or tag [1]. When you trigger the workflow manually—whether via the GitHub UI, the GitHub CLI (gh), or the REST API—you explicitly select the target reference (branch or tag) [1][4]. Key context variables for the triggered run will reflect the selected reference: 1. github.ref: This will contain the fully-formed reference of the branch or tag you selected during the dispatch (e.g., refs/heads/my-feature-branch) [5][6]. 2. github.sha: This will contain the commit SHA of the last commit on the selected branch or tag at the time of the trigger [6]. If you are using the GitHub CLI, you can specify the target branch using the --ref flag [7][1]: gh workflow run --ref Similarly, when using the REST API, you provide the ref as a parameter in the request body [4]: POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches { "ref": "my-branch-name" } If you need the workflow to exist on a non-default branch for development purposes, it must either be merged into the default branch first, or the workflow must have been run at least once on that branch to be registered by GitHub [7]. Alternatively, you can temporarily add a push or pull_request trigger to your workflow to register it on a feature branch, then remove those triggers once the workflow is visible in the Actions UI [7].
Citations:
🏁 Script executed:
Repository: CCExtractor/taskwarrior-flutter
Length of output: 2521
🏁 Script executed:
Repository: CCExtractor/taskwarrior-flutter
Length of output: 9205
🌐 Web query:
site:github.com/actions/checkout README ref defaults GITHUB_SHA workflow_dispatch💡 Result:
When using the actions/checkout action, the ref input defaults to the specific reference or SHA that triggered the workflow [1][2]. This ensures that the code checked out into the GITHUB_WORKSPACE matches the commit SHA represented by the GITHUB_SHA environment variable for that specific event [1][3]. For workflow_dispatch events, GITHUB_SHA points to the commit SHA of the branch or tag selected when manually triggering the workflow. Because actions/checkout defaults to this same ref/SHA, the code checked out will align with that triggered commit [1][2]. Key points regarding this behavior: 1. GITHUB_SHA is tied to the event that triggered the workflow [4][5]. 2. The actions/checkout action, by default, checks out the reference (branch, tag, or commit SHA) that triggered the workflow [1][2]. 3. If you do not provide an explicit ref input to actions/checkout, it uses this default triggering reference [1][2]. 4. It is important to note that actions/checkout runs in "detached HEAD" mode by default, meaning it does not check out a specific branch name, but rather the precise commit [2]. If you require a different behavior (such as checking out a different branch or specific commit), you must explicitly set the ref input [1][3].
Citations:
🏁 Script executed:
Repository: CCExtractor/taskwarrior-flutter
Length of output: 10545
🌐 Web query:
GitHub Actions workflow_dispatch security untrusted branch secrets manual dispatch selected ref official documentation💡 Result:
Using workflow_dispatch to trigger workflows manually introduces significant security considerations, particularly when the workflow interacts with secrets or untrusted code branches. 1. Manual Dispatch Requirements: The workflow_dispatch event only triggers workflows located on the repository's default branch [1][2]. While manual triggers are convenient, they require write access to the repository to execute [2]. 2. Security Risks of Untrusted Branches: When using workflow_dispatch to allow execution on branches other than the default branch (e.g., via the --ref flag in the GitHub CLI or API), you risk executing malicious code [3][2]. If a workflow checks out an untrusted branch and then performs privileged operations, an attacker could potentially steal repository secrets or compromise the runner [3][4]. Never use raw user input (like a branch name or ref) directly in an actions/checkout step without strict validation [3]. 3. Mitigating Script Injection: User inputs in workflow_dispatch events are untrusted [5][6]. If these inputs are interpolated directly into shell commands (the run keyword), they can lead to remote code execution [4]. Always: - Use intermediate environment variables to pass inputs into run blocks [7][8]. - Quote inputs (e.g., "${{ inputs.name }}") [4]. - Use type: choice for inputs whenever possible to restrict values to a known allowlist [4]. - Validate all strings against a strict regex or allowlist before use [4]. 4. Protecting Secrets: Secrets are available to workflows triggered by workflow_dispatch [9]. Because any user with write access can trigger these workflows, you must ensure the workflow logic itself does not inadvertently expose secrets or perform dangerous actions based on untrusted user-provided inputs [6][4]. For critical operations, consider using protected environments, which can require manual approval from specific teams or users even for manually triggered workflows [1]. 5. Best Practices: - Keep workflows that use secrets simple and avoid mixing them with logic that processes untrusted inputs [10][6]. - If you must allow running on different branches, pin the checkout to an immutable commit SHA rather than a mutable branch name [9]. - Implement a gate job that validates all inputs (including branch/SHA references) before proceeding to sensitive steps [9][4].
Citations:
Reject manual runs from non-default refs.
workflow_dispatchaccepts a branch or tag ref, andactions/checkout@v4checks out that selected ref by default. The job writes signing secrets to files before running the selected ref’s build code, then force-pushes its APK tofdroid-repo. Add a job-level guard that permits onlyrefs/heads/${{ github.event.repository.default_branch }}. Keepgithub.sha; it matches the commit checked out by the current configuration.🤖 Prompt for AI Agents
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: CCExtractor/taskwarrior-flutter
Length of output: 10981
🌐 Web query:
GitHub Actions workflow_dispatch branch ref actions/checkout default ref GITHUB_TOKEN permissions checkout persist-credentials documentation💡 Result:
The workflow_dispatch event allows you to manually trigger GitHub Actions workflows [1][2]. When triggering workflows manually via the GitHub UI, you can select the branch to run against [1][2]. To trigger a workflow on a branch other than the default branch using the GitHub CLI, you must use the --ref flag (e.g., gh workflow run WORKFLOW --ref BRANCH) [1][2]. Note that the workflow file itself must exist on the default branch to be visible and available for manual dispatch [1][2]. For the actions/checkout action, the following details apply: 1. Default Ref: When checking out the repository that triggered the workflow, the action defaults to the reference or SHA for that event [3][4]. Otherwise, it defaults to the repository's default branch [3][4]. 2. GITHUB_TOKEN Permissions: To ensure the checkout action functions properly, it is recommended to set the GITHUB_TOKEN permissions to at least contents: read [3][4]. If you need to perform authenticated git operations (like pushing changes) using this token, you may require additional write permissions [5]. 3. Persist-Credentials: This input controls whether the authentication token (or SSH key) is configured with the local git config [6][7]. It defaults to true, which allows subsequent git commands in your workflow to be authenticated [8][6]. The token or key is removed during post-job cleanup [8][6]. Setting persist-credentials: false opts out of this behavior, which can be useful for enhanced security if you do not need to perform further authenticated git operations [6][7].
Citations:
🏁 Script executed:
Repository: CCExtractor/taskwarrior-flutter
Length of output: 3922
🏁 Script executed:
Repository: CCExtractor/taskwarrior-flutter
Length of output: 1052
Declare the minimum
GITHUB_TOKENpermission.The force-push uses credentials persisted by
actions/checkout. Add job-scopedcontents: writeto avoid read-only failures and broader default access.🤖 Prompt for AI Agents
Source: Linters/SAST tools