We recently published a new version of existing artifacts. The version shows up if I explicitly type the version number in the URL.
https://mvnrepository.com/artifact/com.microsoft.azure.functions/azure-functions-java-library-rabbitmq/2.0.0-preview
https://search.maven.org/artifact/com.microsoft.azure.functions/azure-functions-java-library-rabbitmq/2.0.0-preview/jar
But they are not listed on the artifact page.
https://mvnrepository.com/artifact/com.microsoft.azure.functions/azure-functions-java-library-rabbitmq
https://search.maven.org/artifact/com.microsoft.azure.functions/azure-functions-java-library-rabbitmq
Is this is an issue with naming of the version or change in some other properties (I made quite a few) in the POM file?
It seems to take a few days before the new version gets listed. It would be good to know the reason for this delay. mvnrepository.com now shows 2.0.0-preview version. I expect search.maven.org to also show it in a couple of days.
Publication takes around 30 minutes, while the search engine might take several hours to be updated.
Quoting from the Central repository guide:
Upon release, your component will be published to Central: this typically occurs within 30 minutes, though updates to search can take up to four hours.
Related
I use Bamboo regularly as a QA tester to deploy pull requests and feature branches/release branches, but I'm not a developer and have a layman's understanding of how it works.
Our Bamboo configuration is set up to remove inactive branches after a certain amount of time (2 weeks) which happens pretty regularly with longer-term projects, unfortunately. (When that happens, I do know how to configure a new plan and run a new build.) Often, with these larger projects, they've been deployed manually many times over the course of the project, resulting in a large list of possible "release" versions when I go to "Promote existing release to this environment."
Now, I have a brand-new build of a brand-new plan for a project I've been working on off and on for a year and I would like to delete all these old builds (releases?) that show up in the dropdown when I want to just deploy the current version of the current new build, but I can't figure out where to do it (neither can the devs I've asked, but it's NBD to them, whereas this is a constant annoyance for me).
All the advice I can find online says things like "all builds are automatically deleted when the branch expires ...." and that doesn't seem to be true, because these are definitely from old expired plan branches. They also explain how to delete things manually .... from an existing plan branch, which I don't have, because the older plan branches expired and were removed.
Am I using the wrong terminology here and these aren't "builds" and there's a separate way to delete them? Do we have a setup that's failing to delete them when it should? Do devs need to do something different with their branches? I obviously don't have access to global settings but I could put in a request if that's what needs to change.
To be clear, I'm talking about going to deployment preview, selecting "promote existing release to this environment," entering in the jira number/beginning of the branch name, and seeing a million of these (which all look identical because our branch names are hella long):
deployment preview screenshot
I have read through all the Bamboo documentation relating to plans, builds, branches, and deployment, and Googled various combinations of relevant keywords and haven't found a solution. I've also asked devs I work with and they don't know either.
I am having hard time understanding Read the Docs version control for my documentation (may be because of lack my understanding!).
All my project documents are hosted on GitHub and I am trying to setup versions for my document that needs to be in-sync with the latest development releases.
How to manage these doc versions/what are the configurations in sphinx config?
Is there a way I can time travel my document. i.e., If I want to see
any older version of my doc, how can I (re)publish this on Read the
Docs?
Currently, what I am doing:
For a particular development release cycle (say rc1.2), I communicate with the engineers for the changes and I make those changes to my doc; merge the feature PR to main branch. On merging, Read the Doc builds a latest version (latest is pointing to main).
How to see the changes for rc1.0, rc1.1. I am thinking of creating something like change_log.rst and list the changes for each releases. But this would be something only for reference. How to manage these in Read the docs on admin/GitHub?
I use JetBrains intellij for JavaScript NodeJS development.
I was trying to find some code I haven't committed in Git but have overwritten since couple of weeks ago. How far back and how much detail is Intellij's local history?
Can I find this change ever again?
The retention period for local history varies according to the version of IntelliJ.
For example in 2017.x and in 2016.x:
Local history is cleared when you install a new version of IntelliJ IDEA or when you invalidate caches. Therefore, check in the changes to your version control system before performing these operations.
But in 2018.x (see the section titled Retention period for Local History):
By default, Local History is configured to store revisions for the last 5 working days (that is, days when the file was modified).
The 2018.x link includes instructions on how to extend the default retention period including this suggestion:
You can change the default period of how many days local history will be kept for
See also: https://stackoverflow.com/a/11829639/2000323
We have a Nexus repository, that holds our software (surprise ...). In our IDEs, we added the repositories, so we can navigate them in a visual manner.
Problem: the IDE uses the .index folder (with it's gz file), which is currently updated every night.
What I want is: if anyone adds an artifact, the .index should be updated automatically. Is that possible?
What I don't want is: make the index update itself every so many minutes.
Exporting the index into the consumable binary and chunking out the indexes isn't a trivial process so it's not something we've setup to allow publishing every time a release or snapshot is published. It's also a waste because it's unlikely that consumers of the index are updating every n seconds.
The internal indexes are however updated in realtime and searches against the Nexus UI will have the latest and greatest. We are working on more tightly integrating the IDE and Nexus internal indexes to eliminate the publish/consume loop.
I need to find out that how many times and which files are fixed or changed due to a bug between two specific dates in an open source project which uses Trac. I selected Webkit project for that purpose. (https://trac.webkit.org/) However, it can be any open source project.
What can I do for that? How do I start? Do i have to use version control systems like svn or git for intergration? I am kinda newbie for these bug-tracking and issue-tracking systems.
I'm not certain I exactly understand your question, but...
If you browse to the directory containing the files you care about in the Trac site, then click on Revision Log, you will get a list of changesets that affected that directory. You can select the revisions that span the timeframe of interest and then View changes and you will get a summary of the changes, and depending on the size of the changes and the particular Trac configuration, you may get the diffs on that page as well.
Now, that won't tell you how many times those files were changed, just the net changes.
It also won't tell you which bugs those changes were for.
If you really need to filter on what bug, you'll have to determine how that information is tracked by the particular project; and some might not track it directly. The project might include a #123 in the commit message. If you can rely on that, you could use svn log --xml {2009-11-01}:{2009-12-01} ... to get an xml version of the commit log which you could then parse and filter based on the presence of the bug's ticket number in the commit message. From that, you should have a list of the revisions that you care about.