Home
last modified time | relevance | path

Searched +full:release +full:- +full:workflow (Results 1 – 25 of 27) sorted by relevance

12

/llvm-project/.github/workflows/
H A Dissue-release-workflow.yml1 # This contains the workflow definitions that allow users to test backports
2 # to the release branch using comments on issues.
4 # /cherry-pick <commit> <...>
6 # This comment will attempt to cherry-pick the given commits to the latest
7 # release branch (release/Y.x) and if successful, push the result to a branch
12 # This comment will create a pull request from <branch> to the latest release
15 name: Issue Release Workflow
23 - created
24 - edited
27 - opened
[all …]
H A Drelease-sources.yml1 name: Release Sources
9 release-version:
10 description: Release Version
15 release-version:
16 description: Release Version
26 - '.github/workflows/release-source
[all...]
H A Dpr-request-release-note.yml1 name: PR Request Release Note
9 - closed
12 request-release-note:
13 if: >-
15 startsWith(github.ref, 'refs/heads/release')
17 runs-on: ubuntu-latest
21 - name: Checkout Scripts
24 sparse-checkout: |
26 llvm/utils/git/github-automation.py
27 sparse-checkout-cone-mode: false
[all …]
H A Dlld-tests.yml10 - 'release/**'
12 - 'lld/**'
13 - '.github/workflows/lld-tests.yml'
14 - '.github/workflows/llvm-project-tests.yml'
15 - '!llvm/**'
18 - 'release/**'
20 - 'lld/**'
21 - '.github/workflows/lld-tests.yml'
22 - '.github/workflows/llvm-project-tests.yml'
23 - '!llvm/**'
[all …]
H A Dlibclc-tests.yml10 - 'release/**'
12 - 'libclc/**'
13 - '.github/workflows/libclc-tests.yml'
14 - '.github/workflows/llvm-project-tests.yml'
15 - '!clang/**'
16 - '!llvm/**'
19 - 'release/**'
21 - 'libclc/**'
22 - '.github/workflows/libclc-tests.yml'
23 - '.github/workflows/llvm-project-tests.yml'
[all …]
H A Dlldb-tests.yml10 - 'release/**'
12 - 'lldb/**'
13 - '.github/workflows/lldb-tests.yml'
14 - '.github/workflows/llvm-project-tests.yml'
15 - '!clang/**'
16 - '!llvm/**'
19 - 'release/**'
21 - 'lldb/**'
22 - '.github/workflows/lldb-tests.yml'
23 - '.github/workflows/llvm-project-tests.yml'
[all …]
H A Dclang-tests.yml10 - 'release/**'
12 - 'clang/**'
13 - '.github/workflows/clang-tests.yml'
14 - '.github/workflows/llvm-project-tests.yml'
15 - '!llvm/**'
18 - 'release/**'
20 - 'clang/**'
21 - '.github/workflows/clang-tests.yml'
22 - '.github/workflows/llvm-project-tests.yml'
23 - '!llvm/**'
[all …]
H A Dissue-write.yml6 - "Check code formatting"
7 - "Check for private emails used in PRs"
8 - "PR Request Release Note"
10 - completed
16 pr-comment:
17 runs-on: ubuntu-latest
19 pull-requests: write
27 - nam
[all...]
H A Dci-post-commit-analyzer.yml1 name: Post-Commit Static Analyzer
9 - 'release/**'
11 - 'clang/**'
12 - 'llvm/**'
13 - '.github/workflows/ci-post-commit-analyzer.yml'
16 - opened
17 - synchronize
18 - reopened
19 - closed
21 - '.github/workflows/ci-post-commit-analyzer.yml'
[all …]
H A Dllvm-project-tests.yml17 default: '["ubuntu-latest", "windows-2019", "macOS-13"]'
40 # Use windows-2019 due to:
41 # https://developercommunity.visualstudio.com/t/Prev-Issue---with-__assume-isna
[all...]
H A Dlibclang-abi-tests.yml10 - 'release/**'
12 - 'clang/**'
13 - '.github/workflows/libclang-abi-tests.yml'
16 - 'release/**'
18 - 'clang/**'
19 - '
[all...]
H A Dllvm-tests.yml10 - 'release/**'
12 - 'llvm/**'
13 - '.github/workflows/llvm-tests.yml'
14 - '.github/workflows/llvm-project-tests.yml'
17 - 'release/**'
[all...]
H A Dlibcxx-build-and-test.yaml1 # This file defines pre-commit CI for libc++, libc++abi, and libunwind (on Github).
4 # when a job fails early in the pipeline. This is why the jobs are marked as `continue-on-error: false`.
11 # Therefore, we "fail-fast" for any failures during stages 1 & 2, meaning any job failing cancels all other running jobs,
13 # However, stage 3 does not fail fast, as it's more likely that any one job failing is a flake or a configuration-specific
19 - 'libcxx/**'
20 - 'libcxxabi/**'
21 - 'libunwind/**'
22 - 'runtimes/**'
23 - 'cmak
[all...]
/llvm-project/third-party/benchmark/docs/
H A Dreleasing.md1 # How to release
5 * `parallel -j0 exec ::: test/*_test` can help ensure everything at least
7 * Prepare release notes
8 * `git log $(git describe --abbrev=0 --tags)..HEAD` gives you the list of
12 to the release version you're creating. (This version will be used if benchmark is installed
23 * Create a release through github's interface
26 * `git pull --tags`
27 * `git tag -a -f <tag> <tag>`
28 * `git push --force --tags origin`
31 …* IMPORTANT: When re-running manually, make sure to select the newly created `<tag>` as the workfl…
/llvm-project/third-party/benchmark/
H A DREADME.md3 …-and-test](https://github.com/google/benchmark/workflows/build-and-test/badge.svg)](https://github…
5 …k/workflows/pylint/badge.svg)](https://github.com/google/benchmark/actions?query=workflow%3Apylint)
6 …st-bindings](https://github.com/google/benchmark/workflows/test-bindings/badge.svg)](https://githu…
40 [Discussion group](https://groups.google.com/d/forum/benchmark-discuss)
63 See [Platform-Specific Build Instructions](docs/platform_specific_build_instructions.md).
67 This describes the installation process using cmake. As pre-requisites, you'll
79 $ cmake -E make_directory "build"
81 $ cmake -E chdir "build" cmake -DBENCHMARK_DOWNLOAD_DEPENDENCIES=on -DCMAKE_BUILD_TYPE=Release ../
83 # cmake -DCMAKE_BUILD_TYPE=Release -S . -B "build"
85 $ cmake --build "build" --config Release
[all …]
/llvm-project/llvm/utils/
H A Dcount_running_jobs.py3 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
9 python3 ./count_running_jobs.py --token=<github token>
24 .get_repo("llvm/llvm-project")
30 for workflow in workflows:
31 for job in workflow.jobs():
34 # to pull in a PyGithub release that has the runner_group_name property
35 # for workflow jobs.
44 print(f"{workflow.name}/{job.name}")
57 "--token",
64 "--output-file",
[all …]
/llvm-project/llvm/docs/
H A DGitHub.rst1 .. _github-reviews:
10 `Source Code <https://github.com/llvm/llvm-project>`_,
11 `Releases <https://github.com/llvm/llvm-project/releases>`_,
12 `Issue Tracking <https://github.com/llvm/llvm-project/issues>`_., and
13 `Code Reviews <https://github.com/llvm/llvm-project/pulls>`_.
22 intended to be able to support "stacked" pull-request. Do not create any branches in the
23 llvm/llvm-project repository otherwise, please use a fork (see below). User branches that
24 aren't associated with a pull-request **will be deleted**.
32 Graphite will want to create branches under ``llvm/llvm-project`` rather than your
39 If you didn't do the above and Graphite created non-prefixe
[all...]
H A DHowToReleaseLLVM.rst2 How To Release LLVM To The Public
8 This document contains information about successfully releasing LLVM ---
9 including sub-projects: e.g., ``clang`` and ``compiler-rt`` --- to the public.
10 It is the Release Manage
[all...]
H A DBuildingADistribution.rst12 combination of LLVM sub-project tools for distribution. This document covers
30 In deciding how to build your distribution there are a few trade-offs that you
53 workflow only. Due to design and implementation decisions, LLVM relies on
56 LLVM-based tools.
63 .. code-block:: console
65 $ cmake -G Ninja -C <path to clang>/cmake/caches/DistributionExample.cmake <path to LLVM source>
66 $ ninja stage2-distribution
67 $ ninja stage2-install-distribution
69 Difference between ``install`` and ``install-distribution``
70 -----------------------------------------------------------
[all …]
H A DAdvancedBuilds.rst11 `CMake <http://www.cmake.org/>`_ is a cross-platform build-generator tool. CMake
26 can be passed to CMake using the :code:`-C` flag as demonstrated in the examples
32 The Clang CMake build system supports bootstrap (aka multi-stage) builds. At a
33 high level a multi-stage build is a chain of builds that pass data from one
37 In a simple two-stage bootstrap build, we build clang using the system compiler,
38 then use that just-built clang to build clang again. In CMake this simplest form
42 .. code-block:: console
44 $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \
45 -DCLANG_ENABLE_BOOTSTRAP=On \
46 -DLLVM_ENABLE_PROJECTS="clang" \
[all …]
H A DHowToAddABuilder.rst28 commits from the llvm-zorg repository.
52 with the "config owner". We do expect "resource owners" - who are generally
53 the contact listed in a workers attributes - to proxy requests to the relevant
74 of parallelism (-j param) would give the fastest build. You can build
77 #. Install buildbot-worker (currently we are using buildbot version 2.8.4).
79 as ``pip3 install buildbot-worker==2.8.4``.
81 #. Create a designated user account, your buildbot-worker will be running under,
84 #. Choose the buildbot-worker root directory (all builds will be placed under
85 it), buildbot-worker access name and password the build master will be using
86 to authenticate your buildbot-worke
[all...]
H A DGettingStarted.rst19 C-like languages use the `Clang <https://clang.llvm.org/>`_ front end. This
21 -- and from there into object files, using LLVM.
34 * ``git clone https://github.com/llvm/llvm-project.git``
37 ``git clone --config core.autocrlf=false
38 https://github.com/llvm/llvm-project.git``
39 * To save storage and speed-up the checkout time, you may want to do a
40 `shallow clone <https://git-scm.com/docs/git-clon
[all...]
/llvm-project/llvm/utils/git/
H A Dgithub-automation.py3 # ======- github-automation - LLVM GitHub Automation Routines--*- python -*--==#
7 # SPDX-Licens
[all...]
/llvm-project/llvm/docs/Proposals/
H A DGitHubMove.rst22 infrastructure) will continue to work with a Git-based LLVM.
29 This proposal relates only to moving the hosting of our source-code repository
31 using GitHub's issue tracker, pull-requests, or code-review.
35 username/password-hash.
41 ----------------
57 --------
66 through the Git-SVN integration.
82 -----------
85 projects. Any of these could replace the code-hosting infrastructure that we
92 BitBucket: it offers read-write **SVN** access to the repository
[all …]
/llvm-project/clang-tools-extra/docs/clang-tidy/
H A DContributing.rst5 :program:`clang-tidy` has several own checks and can run Clang static analyzer
8 Checks are organized in modules, which can be linked into :program:`clang-tidy`
9 with minimal or no code changes in :program:`clang-tidy`.
13 report them in a way similar to how Clang diagnostics work. A fix-it hint can be
16 The interface provided by :program:`clang-tidy` makes it easy to write useful
20 There are a few tools particularly useful when developing clang-tidy checks:
25 * :program:`pp-trace` logs method calls on `PPCallbacks` for a source file
27 * :program:`clang-query` is invaluable for interactive prototyping of AST
29 * `clang-check`_ with the ``-as
[all...]

12