Re: [OS-BUILD PATCHv10] Add new os-build targets: rt-devel and automotive-devel

2024-01-29 Thread Scott Weaver (via Email Bridge)
From: Scott Weaver on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2732#note_1747883754

This topic doesn't need to block this MR and later if we decide to change it
we can do that. For now let's get this running and see what we learn from
running it daily.
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [OS-BUILD PATCHv10] Add new os-build targets: rt-devel and automotive-devel

2024-01-28 Thread Scott Weaver (via Email Bridge)
From: Scott Weaver on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2732#note_1746932321

I think we want `RT_DEVEL_BRANCH` here instead of `RT_AUTOMATED_BRANCH` or any
patches added to `os-build-rt-devel` will not be propagated to the automotive
branch. Maybe we don't want that to avoid potential merge conflicts but I was
thinking that we would want to revert `f748a60b0b253 ('redhat: TEMPORARY set
configs to deal with PREEMPT_RT not available')` in the rt-devel branch and
have that merged automatically to automotive-devel. In other words, have the
automotive branch inherit a working kernel-rt configuration.
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [OS-BUILD PATCHv10] Add new os-build targets: rt-devel and automotive-devel

2024-01-27 Thread Don Zickus (via Email Bridge)
From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2732#note_1746544615

rebased to drop an old commit @scweaver noticed.
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[OS-BUILD PATCHv10] Add new os-build targets: rt-devel and automotive-devel

2024-01-27 Thread Don Zickus (via Email Bridge)
From: Don Zickus 

Add new os-build targets: rt-devel and automotive-devel

This is an attempt to automate the rt and automotive devel branches
using the upstream linux-rt-devel tree as the base combined with
os-build.

The overall process isn't too complicated but there are enough steps to
make it compilicated.

Steps:
* map upstream linux-rt-devel to master-rt branch
* update os-build
* grab linux version from master-rt and os-build
* if version the same then merge os-build and master-rt to
  os-build-rt-automated
* else merge tag kernel-N.V.0-0 and master-rt to os-build-rt-automated until
  master-rt is update to os-build
* merge os-build-rt-automated into os-build-rt-devel
* merge os-build-rt-automated into os-build-automotive-devel
* run the generate pending-rhel config scripts on rt-devel and
  automotive-devel

The script has beginning logic to handle rebasing if necessary when the
rt-devel branch transitions from os-build-stable (linux-stable) to linux
master again.

NOTE: The script uses kernel-N.V.0-0 which is rebased after os-build
linux-x.y GA is created but before linux-x.y+1 pre-rc1 merges happen.
The reason for this is because linux-stable-x.y doesn't exist until
linux-x.y+1-rc1 exists thus leaving linux-stable-x.y-1 in the meantime.
An awkward gap exists, use kernel-N.V.0-0 as the base.

The script has no effect on the day-to-day operations of os-build.  They
are designed to be run from a gitlab cron job and update in the
background.  Once they are deemed stable, adding ARK MRs that target
either os-build-rt-devel or os-build-automotive-devel will be possible
and those branches can start proper parallel developement with os-build.

Cleanup namespace pollution because shellcheck doesn't like 'local'.

Signed-off-by: Don Zickus 

diff --git a/redhat/scripts/ci/ark-ci-env.sh b/redhat/scripts/ci/ark-ci-env.sh
index blahblah..blahblah 100644
--- a/redhat/scripts/ci/ark-ci-env.sh
+++ b/redhat/scripts/ci/ark-ci-env.sh
@@ -8,24 +8,188 @@ die()
 
 ci_pre_check()
 {
-   if test -n "${TO_PUSH}"; then
-   if test -z "${GITLAB_PROJECT_URL}" || test -z 
"$GITLAB_PROJECT_PUSHURL"; then
-   echo "To enable git-push, please run:"
-   echo "git remote add gitlab "
-   echo "git remote set-url --push gitlab "
+   if test -z "${GITLAB_PROJECT_URL}" || test -z 
"$GITLAB_PROJECT_PUSHURL"; then
+echo "To enable git-push, please run:"
+   echo "git remote add gitlab "
+   echo "git remote set-url --push gitlab "
+   if test -n "${TO_PUSH}"; then
die "Misconfigured 'gitlab' entry for git"
fi
 fi
 git diff-index --quiet HEAD || die "Dirty tree, please clean before 
merging."
 }
 
+# wrapper around branches that may not be exist yet
+ark_git_branch()
+{
+   _target_branch="$1"
+   _source_branch="$2"
+
+   # switch to branch if it exists otherwise create and set to source
+   # branch
+   git show-ref -q --heads "$_target_branch" || \
+   git branch "$_target_branch" "$_source_branch"
+}
+
+# GitLab can only mirror one project at a time.  This wrapper function does
+# the mirroring for any other branches.
+ark_git_mirror()
+{
+   target_branch="$1"
+   upstream_tree="$2"
+   source_branch="$3"
+   reset_branch="$4"
+
+   prev_branch="$(git rev-parse --abbrev-ref HEAD)"
+   remote_branch="$upstream_tree/$source_branch"
+   ark_git_branch "$target_branch" "$remote_branch"
+   git checkout "$target_branch"
+   git fetch "$upstream_tree" "$source_branch"
+   if test -z "$reset_branch"; then
+   git merge "$remote_branch" || die "git merge $remote_branch 
failed"
+   else
+   git reset --hard "$remote_branch" || die "git reset 
$remote_branch failed"
+   fi
+   git checkout "$prev_branch"
+}
+
+# Merge wrapper in case issues arise
+ark_git_merge()
+{
+   source_branch="$1"
+   target_branch="$2"
+   reset_branch="$3"
+
+   prev_branch="$(git rev-parse --abbrev-ref HEAD)"
+   ark_git_branch "$target_branch" "$source_branch"
+   git checkout "$target_branch"
+   if test -n "$reset_branch"; then
+   # there are cases when the initial merge is a reset
+   git reset --hard "$source_branch"  || die "git reset 
$source_branch failed"
+   elif ! git merge -m "Merge '$source_branch' into '$target_branch'" 
"$source_branch"; then
+   git merge --abort
+   printf "Merge conflict; halting!\n"
+   printf "To reproduce:\n"
+   printf "* git checkout %s\n" "${target_branch}"
+   printf "* git merge %s\n" "${source_branch}"
+   die "Merge conflicts"
+   fi
+
+   git checkout "$prev_branch"
+   return 0
+}
+
+ark_git_rebase()
+{
+   rebase_branch="$1"
+   _upstream="$2"
+   _base="$3"
+
+