Epics build on rocky9 #12
Open
Conversation
This file contains 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
…extension. Hack to get around not having substring 'module' in the url.
Check for tag already checked out was incorrect leading to unneeded refetch. Also fixed places where code assumed the current URL was the same as remote origin's url. That fails for repos originally cloned from AFS repos that are now hosted on github.
Was getting many github api errors as code was generating tons of queries for github paths that don't exist.
Can be quite helpful when trying to debug epics-build when AFS may or may not be available, and most but not all EPICS repos have been moved to github.com:slac-epics
JJL772
approved these changes
Mar 4, 2025
Comment on lines
+422
to
+429
| defRepoPath = DEF_GITHUB_REPOS + '/' + gitPackageDir | ||
| if 'github.com' in gitRoot: | ||
| # This results in an extra github API access, but is needed to test if the package is hosted on github | ||
| repoTags = gitGetRemoteTags( defRepoPath, verbose=verbose ) | ||
| if len(repoTags) > 0: | ||
| if verbose: | ||
| print( "determinePathToGitRepo: github %s repo is %s" % (packagePath, defRepoPath) ) | ||
| return defRepoPath |
There was a problem hiding this comment.
Another option here might be to check if $GIT_SITE_TOP/path/to/repo.git/hooks/pre-receive exits with an error not. The modules & packages that we migrated to GitHub have a pre-receive hook that prints an error message and exits return code 1. If the pre-receive hook exits with 0, then you can do the extra github.com check.
|
Looks like we can't try to execute the pre-receive hook.
It would work for the new hook script you created as it just does some echoes and an exit 1.
The default pre-receive hook still used by the repos we haven't moved to github yet
has a while loop that waits till the git connection has read all the pre-receive sets.
If we try to run it standalone it waits forever.
We may need to find another solution for this.
Ideally we should be able to test if the AFS repo is valid, but it looks like a clone or fetch operation
would succeed without running any of the hook scripts.
If you've pushed all the tags, branches, etc from the AFS git repo to github, why
not just delete the AFS git repo to avoid possible confusion over which one to use?
Note that the code below which tries to fetch the tags from a possible github repo
is only run if we are unable to access eco_modulelist/modulelist.txt or don't find
the specified package in it.
Who handles the actual merge once these pull requests have been approved?
On 3/3/2025 5:12 PM, Jeremy L. wrote:
BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
@JJL772 approved this pull request.
Looks good to me, besides one comment/suggestion. Thanks for fixing this stuff!
________________________________
In git_utils.py<#12 (comment)>:
+ defRepoPath = DEF_GITHUB_REPOS + '/' + gitPackageDir
+ if 'github.com' in gitRoot:
+ # This results in an extra github API access, but is needed to test if the package is hosted on github
+ repoTags = gitGetRemoteTags( defRepoPath, verbose=verbose )
+ if len(repoTags) > 0:
+ if verbose:
+ print( "determinePathToGitRepo: github %s repo is %s" % (packagePath, defRepoPath) )
+ return defRepoPath
Another option here might be to check if $GIT_SITE_TOP/path/to/repo.git/hooks/pre-receive exits with an error not. The modules & packages that we migrated to GitHub have a pre-receive hook that prints an error message and exits return code 1. If the pre-receive hook exits with 0, then you can do the extra github.com check.
—
Reply to this email directly, view it on GitHub<#12 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABPDOJT2AAXL2FMAFSCOMZT2ST4XVAVCNFSM6AAAAABYID52OKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDMNJVGY3TINRQGQ>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
I left them intact to avoid "breaking" all existing clones. Since it's been a couple of months since things have been migrated, most of the AFS repos can probably be deleted. A few have not been migrated to GitHub yet due to invalid commits. Those will need to have their git histories rewritten. Unfortunately GitHub doesn't allow us to disable
Either of us. I was holding off on merging because I wasn't sure if Marcio wanted to review or not. After talking to him, I'm going to go ahead with merging these. |
|
Another ugly solution would be to check if there's a tar.gz for the Git repository in AFS: Or to check the README_github file in the AFS $GIT_ROOT directory: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I got epics-build working on rocky9, specifically psbuild-rocky9, with this branch.
Primarily, I do two things.
Note: I'm seeing issues with github API errors that keep epics-build from building more than around 10 packages. When I first saw this I couldn't even get through one package, but I worked to minimize the number of remote github operations and now can get around 10 or so. I looked into some info on github.com re rate limiting and was able to fetch rate limit data. I didn't see any obvious problem w/ the rate limit data. i.e. No counts showed me exceeding limits, but somehow I still get seemingly random failures.