-
Type:
Bug
-
Status: Done (View Workflow)
-
Priority:
Major
-
Resolution: Not A Defect
-
Component/s: plugin-site
-
Labels:None
-
Similar Issues:
[2017-03-21 01:13:22] <teilo> @danielbeck: @rtyler is there something wrong with https://plugins.jenkins.io/? distfork is showing as the 1.4.1 release which was done ages ago - and not the 1.5.0 done 3 days ago or anything newer?
[2017-03-21 01:13:34] <teilo> it is up to date in the update-center.json
[2017-03-21 01:26:24] <@danielbeck> probably not updating properly, check recent release for how old it is
[2017-03-21 01:54:43] <@danielbeck> teilo right, so the problem is that a quirk of the plugin site is that the data is generated for the state that the master branch is in, while the deployed site may be behind
[2017-03-21 01:55:23] <@danielbeck> teilo since the docker images are built from master, no deployment without first changing the base for the data generator
[2017-03-21 01:55:39] <@danielbeck> teilo that was updated on Friday or Thursday, but no new deployment, so updates are broken
[2017-03-21 01:55:45] <@danielbeck> probably needs a different process
My suggestion: Revert the relationship between 'develop' and 'master', call them e.g. 'master' and 'active'. Generate data from what's on 'active'.
Whenever you open a PR to jenkins-infra to get a new build, sync 'active' from 'master'. This way, you can get docker builds and open infra PRs without having to break the updates in the mean time.
Alternatively, we can just merge 'master' (or 'active' in the above) into generate-data, so they're no longer separate. Could be easier that way, modulo the Jenkinsfile differences (always keep the 'generate-data' behavior).
Having develop and master isn't the probiem. The generate-data Jenkinsfile uses master to build the data but it does so independent of what is deployed. The master job on ci.jenkins hasn't been building as of late for reasons I do not know. It times out while inside the docker container so I assume there's something going on there. I don't see the need for a new process. We simply need to figure out why the jobs aren't building. I say that because under reasonable conditions a new build should be deployed within a few hours of master being built.
I'm perfectly happy to attempt to not use docker to build the project but I don't know if/what version of maven is installed on ci.jenkins.
Wrong analysis.
Yet another option: If there's an easy to consume API of the backend, we can check what commit it is inside the 'generate-data' Jenkinsfile, and check out that commit to build the matching data for it.