buildbot/phase1, branch v15

phase1,phase2: s/master/main for phase{1,2}

2024-04-13T04:52:44Z

More and more projects are switching their repositories to use the 'main' branch instead of the 'master' branch. This also includes many Linux upstream trees as well. Some trees are even removing their 'master' branches already. I think this is becoming more and more mainstream and expected of projects, so we should do the same. References: https://openwrt.org/voting/2023-02-27 Signed-off-by: Paul Spooren Signed-off-by: Petr Štetiar [commit facelift]

requirements-dev: use black 23.12.1 and ruff 0.1.9

2024-04-13T04:17:49Z

Fix ruff's recommendation: phase2/master.cfg:328:16: E721 Do not compare types, use `isinstance()` "Unlike a direct type comparison, isinstance will also check if an object is an instance of a class or a subclass thereof." Signed-off-by: Petr Štetiar

Add linting with flake8 tool

2024-04-13T04:17:49Z

flake8 is a Python tool that glues together pycodestyle, pyflakes, mccabe, and third-party plugins to check the style and quality of some Python code. Currently we've issue in phase2 in checksum step: /bin/sh: 2: Syntax error: ")" unexpected And it seems, that flake8 is able to spot places which might lead to such issues during runtime: phase2/master.cfg:733:151: W605 invalid escape sequence '\(' phase2/master.cfg:733:155: W605 invalid escape sequence '\)' phase2/master.cfg:733:158: W605 invalid escape sequence '\(' phase2/master.cfg:733:162: W605 invalid escape sequence '\)' So lets enable flake8 checking on the CI so we can spot similar places in the future and address them before deployment. We dont want to make current ongoing work on phase2 code harder, thus we don't touch that part yet, so we whitelist most of the checks for now. References: f0faed2970dd ("phase2: compute checksums") Signed-off-by: Petr Štetiar

phase1: treat all branches equally for building

2023-11-16T08:57:01Z

Following discussion here: https://lists.openwrt.org/pipermail/openwrt-devel/2023-November/041769.html Signed-off-by: Thibaut VARÈNE

phase1: raise priority of tag builds

2023-11-16T08:57:01Z

Currently the buildmaster would only order tag builds within their own branch, meaning that if e.g. a higher priority branch has normal buildrequests (i.e. buildrequests comming from the AnyBranchScheduler), and a lower priority branch has "tag" buildrequests (i.e. from the Triggerable scheduler), the former builderequests would be served first, deferring the build of e.g. release tags. We want forced builds (release tag) to have maximum priority, regardless of branch priority. This commit attempts to solve this problem by leveraging the newly (as of buildbot 3.9.0) introduced "priority" scheduler parameter, by raising the Triggerable scheduler buildrequests priority, and then considering this higher priority in Builders' order. The net result is that Builders are now prioritized if they have pending higher priority buildrequest, still preserving the branch order. In other words, tag requests are front run while preserving branch order, meaning that if two branches have tag buildrequests, the higher priority branch is still served first. This requires buildbot 3.9.0 Signed-off-by: Thibaut VARÈNE

phase1: workaround dlprune recursive directory removal

2023-07-24T09:06:09Z

Workarounds following issue: find: cannot delete ‘dl/ath10k-ct-firmware-2020-11-08’: Directory not empty References: #13 Signed-off-by: Petr Štetiar

phase1: prepareFactory: use variables instead of list index

2023-07-22T09:05:33Z

Thus make the code more readable. Signed-off-by: Petr Štetiar

phase1: populateTargets: log branch name as well

2023-07-22T09:05:32Z

So the progress is more verbose. Signed-off-by: Petr Štetiar

phase1: do not leak targets between branches

2023-07-22T09:05:31Z

Robert noticed, that after rename of `ipq807x` target in main branch to `qualcommax/ipq807x` subtarget, that buildbot is trying to build this new `qualcommax/ipq807x` subtarget on `openwrt-23.05` branch as well. Thibaut later explained, that this is by design, his initial idea was to find exhaustive list of all targets and let the `checkarch` step do the final triaging. I find this approach confusing, because if the subtarget is not present in that branch, we shouldn't have builder for it configured as well. Furthermore wasting roughly 5 minutes of precious buildworker time to checkout all feeds and then just find out, that we're not going to use those seems suboptimal as well. So lets fix it by using builders for targets as present in respective branches. Fixes: #14 Reported-by: Robert Marko Signed-off-by: Petr Štetiar

phase1: reformat with black

2023-06-18T05:52:37Z

Making everything consistent, more readable, CI guarded. Signed-off-by: Petr Štetiar