Skip to content

Files

Latest commit

4285767 · Sep 13, 2024

History

History

workflows

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
Jun 1, 2024
Jun 1, 2024
Jun 1, 2024
Jun 1, 2024
Jun 1, 2024
Jun 1, 2024
Jun 1, 2024
Jun 1, 2024
Jun 1, 2024
Jun 1, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Jun 1, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Aug 29, 2024
Jun 1, 2024
Jun 1, 2024
Sep 13, 2024
Jun 1, 2024
Jun 1, 2024
Jun 1, 2024

healthtable

healthtable - in addition to information about modules, their stability contains the results of CI/CD of the master and alpha branches.

for_pr_rust_push.yml

actions:

  • install stable rust
  • install nightly rust
  • install willbe
  • run tests with all features, but only on stable toolchain and in debug optimization mode

Groups creates by strategy:

for_pr_rust_push_${{ inputs.module_name }}_${{ github.ref }}_  
 ${{ contains( inputs.commit_message, '+test' ) || startsWith( inputs.commit_message, 'merge' ) }}  

inputs.module_name - name of module
github.ref - name of branch
{{ contains( inputs.commit_message, '+test' ) || startsWith( inputs.commit_message, 'merge' ) }} - returns true if commit message contains directive +test or starts with merge word.

runs if commit message contains directive +test or starts with merge word.

standard_rust_push.yml

actions:

  • install stable rust
  • install nightly rust
  • install cargo-udeps
  • install cargo-audit
  • checks crate with cargo-udeps
  • checks crete with cargo-audit
  • install willbe
  • run tests with all features, with stable and nightly toolchain, with release and debug optimization mode

Groups creates by strategy:

standard_rust_push_${{ inputs.module_name }}_${{ github.ref }}_  
 ${{ contains( inputs.commit_message, '+test' ) || startsWith( inputs.commit_message, 'merge' ) }}  

inputs.module_name - name of module
github.ref - name of branch
{{ contains( inputs.commit_message, '+test' ) || startsWith( inputs.commit_message, 'merge' ) }} - returns true if commit message contains directive +test or starts with merge word.

runs if commit message contains directive +test or starts with merge word.

standard_rust_pool_request.yml

actions:

standard_rust_schedule.yml

actions:

Affects badges in the header of the workspace readme.md file, looks like this wTools.

module_{module_name}_push.yml

actions:

Affects badges that are opposite to modules in the healthtable, as well as badges in the header of the crate readme.md files.

appropriate_branch.yml

This workflow ensures that pull requests are opened against the correct target branches based on a predefined branching strategy (alpha -> beta -> master). It checks whether the destination branch specified in the pull request matches the expected branch according to the branching strategy. If it doesn't match, the pull request is converted to draft mode, and if it still doesn't match, the workflow fails.

appropriate_branch_beta.yml

This workflow delegates the actual validation and actions to another workflow file (appropriate_branch.yml) located in the Wandalen/wTools repository under .github/workflows directory on the "alpha" branch. It ensures that pull requests targeting the "beta" branch are appropriately validated and processed according to the rules defined in the external workflow file.

appropriate_branch_master.yml

Similar to the previous workflow, this one also delegates the validation and processing of pull requests to an external workflow file (appropriate_branch.yml) located in the Wandalen/wTools repository under the .github/workflows directory on the "alpha" branch.
By specifying the "beta" branch as the source branch and dynamically referencing the base branch of the pull request as the destination branch, this workflow ensures that pull requests targeting the "main" or "master" branches are appropriately validated and processed according to the rules defined in the external workflow file.
This setup promotes consistency and reusability of workflow logic across different branches within the repository, helping to maintain a standardized process for handling pull requests.

auto_merge_to_beta.yml

This workflow automates the process of merging changes from the "alpha" branch into the "beta" branch after ensuring that related workflow runs for modules have completed successfully.
It waits for the completion of workflow runs related to modules and checks their statuses before proceeding with the merge process.
If all checks pass, it merges the changes into the "beta" branch using the provided GitHub token.

auto_pr.yml

This workflow automates the process of opening pull requests between specified source and destination branches.
Upon triggering, it checks out the repository and opens a pull request from the source branch (src_branch) to the destination branch (dst_branch).
The pull request title is automatically generated to indicate that it's an automated pull request forwarding from one branch to another.
If a pull request already exists between the specified branches and PASS_IF_EXISTS is set to true, the action will pass without creating a new pull request.

auto_pr_to_alpha.yml

This workflow automates the process of opening pull requests from any branch except for those explicitly excluded to the "alpha" branch.
It leverages branch filtering to include all branches and exclude specific ones such as master, main, alpha, beta, and any branches containing test or experiment in their names.
When triggered by a push event on a qualifying branch, it calls the external workflow (auto_pr.yml) to handle the process of opening a pull request to the "alpha" branch, passing the source and destination branch information along with the GitHub bot token for authentication.

auto_pr_to_beta.yml

This workflow automates the process of opening pull requests from the "alpha" branch to the "beta" branch.
When triggered by a push event on the "alpha" branch, it calls the external workflow (auto_pr.yml) to handle the process of opening a pull request to the "beta" branch, passing the source and destination branch information along with the GitHub bot token for authentication.

auto_pr_to_master.yml

This workflow automates the process of opening pull requests from the "beta" branch to the "master" branch.
When triggered by a push event on the "beta" branch, it calls the external workflow (auto_pr.yml) to handle the process of opening a pull request to the "master" branch, passing the source and destination branch information along with the GitHub bot token for authentication.

runs_clean.yml

This workflow allows manual triggering to clean up workflow runs in the repository.
It first deletes any runs that have been cancelled or skipped, ensuring that they do not clutter the workflow history.
Then, it deletes runs older than a specified number of days, while ensuring that at least 20 runs are preserved regardless of their age.
By regularly cleaning up older workflow runs, this workflow helps maintain a clean and organized workflow history in the repository.

standard_rust_status.yml

This workflow serves as a status monitor for the completion of specific workflows: "auto_merge_to_beta" and "rust_scheduled."
Upon completion of any of these workflows, it checks the status of their runs.
It employs a matrix strategy to iterate over different workflow files to check their statuses.
If the conclusion of any checked workflow run is "failure," "cancelled," or "skipped," the workflow exits with an error, indicating a problem.

status_checks_rules_update.yml

When a pull request is opened targeting branches "alpha" or "beta":

  • If the base branch is "beta":
    • It compares the contents of the workflow directories between branches "alpha" and "beta".
    • If they are not equal, it triggers an update of branch protection rules for the "beta" branch.
  • If the base branch is "alpha":
    • It directly triggers an update of branch protection rules for the "alpha" branch with specific required status checks for different contexts.