I have a incorrect version of the job where I published to TAC is there a way to get the previous version from the nexus repo
Assuming that you didn't overwrite the artifact it will still be in nexus however if you didn't re-version the code and haven't got backups etc. on your nexus server it's unlikely.
Also you should add more detail on stack overflow posts or they will keep getting downvoted by the community you should include a detailed question including some of the steps you went though to try to resolve you issue.
Lastly if you have TAC your using the enterprise version of Talend which usually means your eligible support from Talend themselves I'll PM you support email address.
Related
I have a GitHub worflow which builds and deploys a snapshot version of a library as a GitHub package, e.g., mycompany.mytool.1.0.0-SNAPSHOT.jar. Whenever I make a new build and deploy, a new asset is created, like, e.g., mycompany.mytool.1.0.0-20210723.145233-1.jar instead which is then somehow associated with the SNAPSHOT tag. This all seems to work and I can access mycompany.mytool.1.0.0-SNAPSHOT.jar without problem.
My question now is, how can I get rid of all these older versions of this jar? Actually I just want to keep the latest version. I can delete them manually via the web-interface but that is a more than awkward task. I would somehow like to automate this too.
This is not possible as of this writing. GitHub staff member Jamie Cansdale wrote this in their community forum:
SNAPSHOT versions are exposed as artifacts inside a regular versions. There isn’t an API for cleaning up artifacts, only whole versions.
(source)
Which means that a single SNAPSHOT version (like 1.0.0-SNAPSHOT) will accumulate all builds you make, and all artifacts will show up on the Assets list to the right of the web page.
The only practical solution I can think of, is that you delete the whole version from a script, before publishing each build's artifacts. Then you'd have the effect of having a single set of artifacts stored as part of the 1.0.0-SNAPSHOT version name.
However this solution is not ideal: public package versions cannot be deleted if they are popular enough (probably to avoid squatting attacks):
If the package is public and the package version has more than 5,000 downloads, you cannot delete the package version. In this scenario, contact GitHub support for further assistance.
It seems that sonar no longer report for my pull requests. In october, it was working: https://github.com/edemo/PDEngine/pull/113
That one was using 7.4.0, which is later than 7.2.0, for which some kind of deprecation was announced here: https://docs.sonarqube.org/latest/setup/upgrade-notes/
Today it does not report: https://github.com/edemo/PDEngine/pull/118
it uses 7.7.0, and no change in the build environment I am aware of.
I have specifically checked that none of the files in the repo which have anything to do with sonar have any relevant changes.
Where should I look for the problem's cause?
It seems that the change is in github. Adding Sonarcloud GitHub app to the organization solved the problem. It is another check than the old one, so I had to update the branch protection rules as well.
Before going forward, I realize this question is too broad. But I couldn't figure out the proper verbiage to search either here in SO or on GOOGLE.
If this question is a duplicate, then please excuse me in advance and provide me the link to the original question.
Problem :
We are working on creating testing framework. One of the requirements is to publish a report at the end of the testing phase with build information. We need to provide information like who committed the latest change we are testing, what is the build version we are using for testing etc.
In our current setup, We are using github as SCM. Whenever there is a commit to the SCM, a build is triggered on Jenkins and if the build is successful, the jar is deployed to JFrog Artifactory. I am trying to come up with a gradle script to get the necessary information.
Any pointers to the following questions are highly appreciated:
Which plugin can I use to retrieve the info for a SNAPSHOT jar from Artifactory?
Which plugin can I use to retrieve Jenkins build info using the build number retrieved from Q1?
Not sure this is what you were asking for, but have you looked into the Artifactory Build Info file?
The Artifactory Jenkins Plugin can collect build information for you and publish that information to the Artifactory server (If you choose to "collect and publish build info").
The build information can then be viewed on the artifactory server and also fetched using a simple REST call.
HTH,
Or
I am trying to see how the OpsHub migration tool works before I perform real migration.
And hence I am trying with a on premise TFS instance and a trial created Team Services (was Visual Studio Online) instance. but when I finish configuring the stuff and it start to validate all the settings put in, it is giving error for Team Services Project Collection URL. It is taking collection URL as
https://********.visualstudio.com/********
where as it should only use
https://********.visualstudio.com/
Not sure how to get over it and now fully stuck.
This is caused by the change in VSTS:
Collection in the domain
Your Team Services account URL just got 18 characters shorter. We’ve
removed “/DefaultCollection” from the path. While it’s small, but
welcome change. It’s the beginning of a larger journey to how we
structure accounts. Learn more here.
Note that existing accounts will still give out the longer URL for Git
Clones in the Code hub. This is because to use the new shorter URL in
VS, you will need to reconnect Team Explorer using the shorter URL.
Today you either need to use the long or the short URL for an account
in VS, you can’t intermingle. Once we have enough clients updated such
that they just work seamlessly with either type, we’ll change the
default Git Clone URL to the shorter one as well.
Last but not least, we have a set of Release Management improvements.
Please download the latest version of OpsHub Visual Studio Migration Utility and then try again.
A similar issue here: OPS Hub - unable to migrate project.
I've been reading up on how people do continuous delivery with some of the popular toolsets.
Lots of posts (like this one) seem to indicate that a common way of doing things is to use something like capistrano to push software from your builds to your machines, and then chef or puppet to configure anything related to it.
My question is, do people generally push there software directly into a special git repo for binary assets, or can capistrano fetch it out of a maven repo? The maven approach seems most natural to me, but I don't seem to be able to find much information on it - which is what makes me think it's not the approach that people are generally taking.
Basically, I'm slightly confused as there seems to be a gap between the build output (where one would normally publish to a maven repo) - and where the delivery tools expect to find the software you have asked them to deploy (which seems to be a file system, or a git repo)
When it comes to artifacts; I attempt to leverage the jenkins plugin to upload to S3. Here's a link to it.
Basiclly right now, all my ci goes through Jenkins and when I get a complete build I upload it to a bucket and have chef pull the tarball/war/gem from it and install it from there.