In the latest version of CDW plugin for Jira (0.9.21) we implemented the feature that enables project administrators to set a default tester for each component of the administered project.
The feature works as following:
In the project administration, the user with admin privileges for the project selects the Component Testers tab leading to the feature UI. There for each component of the project the administrator can insert a username of the user that will be used as a default tester for the component. User picker (icon near the Default Tester input fields) can be used to find a specific user by their email or full name.
Then, once the tester for the components are set in the admin interface of the project, each newly created issue that has the component assigned and no tester set will get assigned this default tester.
Note that to trigger this functionality, exactly one component and no tester must be set in newly created issue.
If more, or no components are set or the tester field is filled on creation, the value of tester field will remain as at the issue creation.
See that the tester in newly created issue was filled according to the preferences set in the project admin UI.
Some people had problems downloading files from the Developers Program. The problem is in processing of company and country fields from the user profile. The most important part of the problem was fixed, however some users still end up in an infinite loop of inserting company and country fields.
If that happens to you, please, go to your profile and set the type of your address to "home". While there, you may also check that the country and company field - they must be filled as well.
We are sorry for the inconvenience. The problem will be fixed tomorrow.
JIRA Agile plugin of jboss.org JIRA has been updated to latest version 6.7.6.
Search by the Sprint field for JIRA's basic search had been introduced in JIRA Agile 6.7.2. In this release, the Epic Link and Epic Name fields has been added as parameters for the basic search. Just navigate to the basic search, click More and add the Epic Link and/or Epic Name field.
jboss.org JIRA server running at https://issues.jboss.org provides streamlined functionality of "Start Progress" action now, which is in align with latest JIRA default workflow.
You had to manually assign issue to yourself to be able to perform "Start Progress" action before this change. Now, the "Start Progress" action is available to all Assignable users (potential developers). Status of the issue is changed and you are made issue's Assignee once you use it, so one less click is necessary and workflow is more user friendly.
Lots of projects hosted in jboss.org JIRA uses original "Git Pull request workflow" created about four years ago. This workflow allow user to manually switch issue to "Pull Request Sent" status once GitHub PR is created, and manually insert URL of pull request into "Git Pull Request" issue field. This workflow allows projects to better track and process Pull Requests, but heavily depends on manual work.
New JIRA features like DVCS plugin and event based workflow transitions introduces in JIRA 6.3 series allowed us now to create better PR tracking workflow, which removes this manual work.
This workflow automatically switch issue to "Pull Request Sent" status once GitHub PR is created and issue key is mentioned in PR's name or description. Pull Request URL is not stored in "Git Pull Request" issue field, but it is visible in "Development" area of JIRA issue detail screen.
JIRA issue is automatically resolved once GitHub PR is merged then. If GitHub PR is refused then no any JIRA issue status change is done.
Project leads who want use this feature for their JIRA project can follow next steps:
GitHub repository must be owned by github "Organization", personal repositories can't be linked
jboss-jira-hook github user must be added into the organization's Owners group. Jira needs this to add webhooks into GitHub repository to track changes immediately.
then you have to email email@example.com with request to add your GitHub repository into JIRA configuration and switch your JIRA project to use "GIT Pull Request workflow with automatic PR triggers workflow scheme". You have to specify which Github repositories do you want to add (all owned by some Organization, or few named only) and which JIRA project should be switched.
Two weeks ago two independent teams ran into the same issue. They deployed artifacts to repository.jboss.org and then they found out, that their builds are failing, because Maven was not able to download some of the checksums. "repository.jboss.org" is an Apache instance, that load balances two Nexus proxy servers to mitigate the load. Both proxy servers read the data from a single master server.
It took us some time to find the reason, because not all check sums were missing and to make things even more interesting, some checksums were missing on just one of the proxies and some on both. Also in some cases sha1 checksum was missing, while md5 was present and vice versa...
We have a good news and a bad news for you. The good news is the builds will no longer crash due to "not found" checksums. Bad news is unless https://issues.sonatype.org/browse/NEXUS-7654 is resolved, directory listings on repository.jboss.org artifacts may not be accurate and it may have missing directories (they do not affect builds, just browsing with a web browser).
What Went Wrong?
For all the servers we use Sonatype Nexus version 2.7. If I want to explain the problem it is important to explain how the Proxy Repository with Smart Proxy feature works.
Proxy Repository works like a cache. You build some project with a dependency on some artifact. Maven has a deterministic way how to calculate the URL of the downloaded file (artifact). Your Maven client calculates this URL and tries to download the file from the calculated location in your proxy server.
Now two things can happen - the proxy repository already has the file and your Maven client downloads it from this location. Or the file is not present in the proxy repository on that URL. The proxy repository has "remote repository" defined. If the file is not found locally, Nexus tries to find the file in the remote repository. Then it either returns and stores the artifact or return not found to your client.
Nexus also knows, that if it downloads an artifact, there may be checksums available for it. The checksum is calculated as <URL of your artifact> + ".md5" or <URL of your artifact> + ".sha1". When Nexus downloads your artifact, it also remembers, if the checksums were present for this artifact.
I mentioned a Smart Proxy Feature. Normally the proxy repository remains empty, unless someone builds his project and his Maven client downloads some files from the proxy. With each build, the proxy repository is slowly filled with artifacts that are requested. This is useful, because if you for example use Maven Central as the remote repository, your proxy server is not flooded by zillions of artifacts from the remote, that no one uses. However directory listings on the proxy server do not display the directory listings of the remotes, but the artifacts cached locally. This means builds are OK, but people browsing such repository often complain about "missing artifacts".
Smart Proxy feature allowed us to solve this problem. Whenever someone deployed artifacts to the master server (= remote repository for the proxies), the smart proxy immediately pushed those to the configured proxy servers. However here lies the pitfall.
In the current version of Nexus when artifacts are released, they are pushed to the proxy servers immediately. Proxy server also checks for existence of checksums, however in some cases the proxy server checks for their existence after the master server releases the artifact but before the master manages to properly release the checksums. The proxy server marks a note the artifact does not have the checksum even if it should have it. And in case your Maven client is configured to always check the checksums, your build will fails.
How We Fixed the Problem
Ideal solution would be to fix the Smart Proxy feature. This will be done sooner or later by Sonatype, you can monitor the progress here https://issues.sonatype.org/browse/NEXUS-7654. However I needed it to be fixed now so the builds do not fail anymore. I had to disable the smart proxy feature for now. That way the artifact is requested by the nearest build and it is very unlikely to happen a microsecond after the artifact is published. That way the master server has enough time to release the checksums as well.
The builds will no longer fail, however due to the continuous populating of the proxy repositories directory listing will not always display all available artifacts. And do you remember I mentioned we have two proxy servers behind a load balancer? If you think it might mean one directory listing could possibly display different artifacts when accessed several times (the same URL), you are right.
There is a way how to fix this, but the way is very annoying. If you are a team leader you should consider it though. After you release your artifacts, you need to download all of them from both proxy servers.
Their URLs are proxy01-repository.jboss.org and proxy02-repository.jboss.org. You have to be in Red Hat intranet and you might have to add those two to your hosts file. The IP address of both is 10.38.5.26.
I would like to thank vladimir_v and Rich Seddon (and his colleagues) from Sonatype for their help during the investigation of the problem. As soon as https://issues.sonatype.org/browse/NEXUS-7654 is fixed and I will update our Nexus to the fixed version and re-enable smart proxy so the both proxy servers become automatically populated again.
People report a bug that when they refresh Maven repository in their web browser (repository.jboss.org), they get different results (missing artifacts). This appears like a big bug, however I would like to shed light into this rather cosmetic problem.
It is caused by our new infrastructure behind repository.jboss.org. Originally there was just one server that handled artifacts. As the load increased this solution started not to be good enough. Therefore we added two proxy machines in front of the original one. They serve as mirrors for the original instance and they are load balanced by Apache. A classical mirror is a complete copy of all artifacts. The proxy machines are not classical mirrors though. The files are served using proxy repositories of Sonatype Nexus, that stores just content people ask for on the machines. When an artifact is requested, Nexus delivers it from the local content and if he does not find it locally it tries to obtain it from the master. However directory listing in the web browser is always served from the locally stored content.
And this is the reason, why the two machines have different directory listing. If one artifact is requested by someone the load balancer uses one of the mirrors and the artifact is added to the directory listing of that particular instance. But when one display the repository listing and then refreshes it, what may happen is that the listing will be displayed from the second instance, that does not have the artifact yet .
So i you worry about your builds - no worry! Both mirrors are identical and always return all the requested artifacts (even if it appears they are not there). Browsing the repositories using web browser may be confusing though. I will fix the issue somehow buthe builds are fine so the problem is not that big as it appears to be.
Today we switched to the new hardware for repository.jboss.org. Two new dedicated servers now serve artifacts to the whole community.
We are happy, that we achieved a significant increase of request handling speed. After one hour of service there are no errors reported yet, but, please, if you find something odd, report it to firstname.lastname@example.org so we can investigate it.
As we announced a week ago, we switched repository.jboss.org to a new hardware. Unfortunately our Apache does not seem to handle current load and so we are switching back to the original hardware. We are sorry for any inconvenience during the last hour.
There were troubles in the past with repository.jboss.org Maven repository, because the server was heavily overloaded by requests from the community. We did quite a lot of optimizations. A part of the load has already been removed by adding Akamai infrastructure in front of product artifacts. Also we added some automatic cleaning tasks to the system and optimized authentication plugin. As a result the server is now quite stable. Calling it fast would be exaggerating though. But there is a hope.....
Next week (2014-07-14 12:00 PM UTC) we scheduled switching the load from one old machine to two brand new servers that would split the load between one another. Why I am writing about it? Well it is a good news for anyone using repository.jboss.org but on the other hand there might be a risk of some issues we are not aware yet.
So I would like to ask project leaders: if you plan some important event on Monday July, 14th (release, conference etc.), please, contact me so we can reschedule the hardware changes to some "safer" date.
We're proud to announce new feature 'Social Log In and Sign Up' for jboss.org website released few days ago.
It allows you to use your Google, GitHub, LinkedIn, Facebook and/or Twitter account to create a new jboss.org user account. You can also link these accounts to your existing jboss.org account.
The linking allows you to login to jboss.org website later without entering other password if you are logged in on Google for example. You can simply resolve "I forgot jboss.org password" cases also, by logging in over linked account and changing jboss.org password then.
You can find Social provider icons directly on jboss.org login page and use them for Log In or Sign Up.
If social account is not linked with any jboss.org account yet, you can do that via next screen allowing you to link it with your existing jboss.org account or create a new one.
Registration form is prefilled by name and email obtained from your social account to save your work a bit.
Later you can manage your Social accounts links from jboss.org user profile page.
Based on statistics this new feature is very useful since aprox. 30% of newly created jboss.org user accounts are created over it now. Google provider is the most popular one, making over three quarters of all uses. Facebook provider is second well ahead of other providers.
"comment by email" feature has been enabled for jira running at issues.jboss.org during today's outage.
It means you can reply to a notification email received from jira, and your text will be added as comment for the issue received email was about.
"Add a comment from the non quoted email body" handler is used. This message handler creates a comment, but only uses the 'non quoted' lines of the body of the email message. A quoted line is any line that starts with a '>' or '|' symbol and such lines of text will not be added to the comment. The issue to which the comment is added is chosen from the first issue key found in the email subject. The author of the comment is taken from the address of the email message's From: field. Messages from unknown email addresses are ignored silently.
As part of this task we have to change email address JIRA uses as From in emails to email@example.com
You have to upgrade your "from JIRA" email filters if they depend on it.