checkin and delivery from local file system to rtc through Jenkins
I need to deliver a folder from my file system to a component in a stream on RTC
I am trying to do this from a jenkins pipeline, using a SCM command sequence but I have not been able to commit the files.
The easiest alternative is to use the RTC plugin for Jenkins (i suppose), but I only use the plugin to do the checkout of a component on a machine, but I don't know how to do the reverse i.e. do a checkin and delivery (commit) from file system to component.
Can this be done with the RTC plugin or in any other way without using an SCM comnand sequence?
|
3 answers
Ralph Schoon (63.1k●3●36●46)
| answered Nov 22 '22, 7:05 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER To my knowledge the Jenkins plugin has the capabilities needed to make the SCM data available to the build. So you can load them down. To my knowledge there is no capability to check in and deliver files during the build using the Jenkins plugin.
As far as I can tell, you would have to use the SCM command line and do it in a postprocessing step after the build. 2 things to consider
1. Build a simple prototype and learn how to SCM command line works first, before trying to do it in the build.
2. From my perspective, the build results do not belong into SCM. The build results should be in some storage and be accessible as HTTP page and linked to the build result. Checking in and delivering build results can lead to failing the checking and deliver which can be hard to detect. Also build results are typically big binaries which do not belong into an SCM system. I know that there are others with different ideas.
|
If your Jenkins server is set up as a build engine then you can define Post Build Deliver in a build job. See my responses in this earlier post:
Comments My interpretation of the question was along the lines, I need to check in and deliver a product of the build. The post build deliver is only able to deliver the version that was accepted into the build workspace to another (green) stream. It actually does not deliver, it sets a baseline as far as I am aware.
If you want to share, check in and deliver new stuff generated in a build, you would have to use the SM command line.
Ah OK,
So I guess it really depends on what the OP is trying to do here.
I think we would both argue that committing the build results into source control is not an optimal approach and that the general rule is that you would not store products of the build in source control, because you can recreate them by rebuilding.
However you do want built files available to then be used during delivery somewhere and that's when I use the Ant Build Toolkit to publish build results
In particular I use the artifactFilePublisher task to attach built components to the build result, or artifactLinkPublisher to attach a link to the built files stored on a shared drive or artefact repository somewhere.
Ralph Schoon
commented Nov 24 '22, 3:39 a.m.
| edited Nov 24 '22, 3:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
My suggestion is to avoid the artifactFilePublisher. The Build result data should be published as HTML be on some storage or binary artifact repository such as Artifactory.
Automatically prune builds no longer required. e.g. see https://rsjazz.wordpress.com/2015/10/28/build-artifacts-publishing-and-automated-build-output-management-using-the-plain-java-client-libraries/
Why do you not recommend the File Publisher Ralph?
If your components are reasonable in size it's not a bad place to store them, especially if you don't have RAM or Artifactory.
I also like the fact there are Ant Built Toolkit commands to retrieve these files as well - I've used this in a deployment build definition that I then chain together in an end to end build definition that will build each component, deploy the parts into a test environment and invoke ETM Test Suites to do burn in or component tests that all get linked back to the build record
Davyd, I think this is just preference. If it works for you, use it.
My preference would be to set up the build infrastructure to keep the build workspace, or the Build result in a file system location or repository that is published as URL. This allows to store all the data you want, including LINT or other validation/verification results there. I find it cleaner to just publish the link back. You can have an index page, you can directly refer to files for download. I find this much cleaner and no build result files would bloat the EWM database. This is also very similar how the builds for ELM work and keep the data.
|
My 2 cents ...
Generally when cmd line utilities (RTC SCM) are invoked from an application (Jenkins), environment variables necessary for the cmd line utility are met as system environment variables are modified by the application for its own purposes. Try setting the environment variables explicitly in your script. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.