dfarrell07 I would be happy to assist with creating the repositories. I need to understand more about the need for scratch pkgs and repo requirements. Do we need a scratch repo per project and per-release? Maybe we should discuss this on a call?
Please note, presently the rpms/debs are being pushed to devel repos [1.] get purged at 30 days (since they are acting as staging repos). Ideally, someone should raise a build promotion requests for the released rpm builds to copy them to official release repos on Nexus and we should have jobs which promote them automatically.
[1] https://nexus.opendaylight.org/content/repositories/opendaylight-{*}-epel-7-x86_64-devel
Thanks for the help askb 
There are two kinda-distinct usecases for the scratch repos:
- Most importantly, want to be able to build propose code into packages and push them there. So a dev would put a keyword in a Gerrit comment, something like the multipatch job will build that into a distro and then something like the build-rpm job will build that into a package. The result should get pushed to these scratch repos for the dev to test.
- Also, it would be cool if we could push to these from the sandbox. So if there is a snapshot distro that was built by something like a merge job, or a multipatch job, then a dev could push the build-rpm job to the sandbox, point it at the snapshot distro in question, trigger a build and have the resulting package pushed to these scratch repos.
Regarding promoting releases - we need to document some process for how that should be done (requested?). I have a WIP patch to document the full int/pack release process here: https://git.opendaylight.org/gerrit/#/c/71650/
Promoting packages on Nexus isn't super critical I think because hosting them on the CBS works fine. http://cbs.centos.org/repos/
dfarrell07 thanks for the detailed explanation. I will work on setting update the repos next week and update here once its ready.
> Promoting packages on Nexus isn't super critical I think because hosting them on the CBS works fine. http://cbs.centos.org/repos/
We are ok with hosting them on CBS, the only caveat here is the *-devel repos have schedule tasks which remove packages older than 30 days from the time of the build (and not actual release), which requires a job in place which push the rpms into CBS or *-release repos soon after the release.
I'm just pushing to the CBS manually for now. I think it would be cool to make a job to do that, but it might be tricky to get credentials that can be used safely in jobs.
dfarrell07 I belive these are going to be used as test repos for testing individual patches, I would recommend we use these as generic devel repos, instead of having a separate repo per-release (oxygen, fluorine .. etc)?
We have two repos available on Nexus2, let me know if these can be used:
ex:
https://nexus.opendaylight.org/content/repositories/opendaylight-epel-7-x86_64-devel
https://nexus.opendaylight.org/content/repositories/opendaylight-ubuntu-1604-x86_64-devel
abelur Yeah, those would work perfectly. Better than maintaining per-stream repos. All we need is somewhere to dump packages.
I'm messing around with some JJB to play with them now.
https://git.opendaylight.org/gerrit/73418 adds some logic that lets me pass opendaylight-epel-7-x86_64-devel as REPO_ID, thereby allowing deploys to that repo.
When running in the sandbox, it seems to work but then we run into an (expected) permission denied error:
Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file (default-cli) on project standalone-pom: Failed to deploy artifacts: Could not transfer artifact org.opendaylight.integration-packaging:opendaylight:rpm:8.2.0-1.el7.noarch from/to opendaylight-epel-7-x86_64-devel (https://nexus.opendaylight.org/content/repositories/opendaylight-epel-7-x86_64-devel): Failed to transfer file: https://nexus.opendaylight.org/content/repositories/opendaylight-epel-7-x86_64-devel/org/opendaylight/integration-packaging/opendaylight/8.2.0-1.el7.noarch/opendaylight-8.2.0-1.el7.noarch.rpm. Return code is: 401, ReasonPhrase: Unauthorized.
abelur Can we setup the sandbox to allow deploys to these scratch repos?
> When running in the sandbox, it seems to work but then we run into an (expected) permission denied error:
That's because we don't allow deploying artifacts to Nexus from sandbox. However, we can provide a temp hook for testing purposes, and remove it once we have tested the jobs
I had a brief discussion with agrimberg regarding setting up CBD credentials on Jenkins. We are not sure what CLI are being used for uploading packages on the CBS system. However, can we create/manage these credentials files or add the creds ~/.netrc (confined only on Jenkins Prod env jobs) and have packaging jobs on releng manage upload the released packages to CBS repos in a timely manner. Also will have to have to figure out a way to setup a separate CBS account for this task.
abelur These are the CBS docs:
https://wiki.centos.org/HowTos/CommunityBuildSystem
https://wiki.centos.org/HowTos/CentosPackager
Would be cool to have this more automated and, most importantly, have someone other than myself with permissions to push to CBS. We're currently at a very low hit-by-bus number there. 
> That's because we don't allow deploying artifacts to Nexus from sandbox. However, we can provide a temp hook for testing purposes, and remove it once we have tested the jobs
Can we enable pushing to some destinations in Nexus? That may be too much to ask, but if it's easier than I anticipate than it would be nice for developers to be able to build in the sandbox and have the resulting package hosted in these scratch repos. See INTPAK-151.
dfarrell07 Please try again, you should be able to push to that scratch repository.
The deploy to scratch repos is working now
abelur - Awesome, confirmed this is working as desired. Thanks!