Yes, that is what I'm referring to. Just to confirm, that is the same URL that your connectors use?
Thanks,
Rich
Yes, that is what I'm referring to. Just to confirm, that is the same URL that your connectors use?
Thanks,
Rich
Hi @mikhael_3947,
I have updated our Docker documentation to include this information about using a proxy with ProGet. I have also included more information about insecure registries and using self-signed certificates with Docker registries,
Thanks,
Rich
Hi Mike,
For the connector issue, can you try setting the Web.BaseUrl
in your Advanced Settings to your DNS name? Please let me know if that works.
For the errors logging the license violation, I'm going to need to dig in a little more on that. I'll let you know when I have more information.
Thanks,
Rich
I did some searching around and it seems like there are a bunch of users that have the same problem in Windows 7. It looks like the FTP server is not using the system's TimeZone and I could not find any way to set it. Unfortunately FTP does not give us a way to determine what timezone use dynamically.
I have created a new CI build, 1.0.1-CI.4, that gives you the ability to use the current date and time as the file modifed date when BuildMaster cannot parse it from the FTP server. You can enable it on the FTP operation by going to the Advanced
tab and set the property of Use current date on error
to true.
Could you please update the extension, set the Use current date on error
property, and give that a try?
Thanks,
Rich
The best way is to just adjust the date/time on each and tell me what timezone is selected in each?
Thanks,
Rich
Are you able to pull successfully using npm and ProGet? Also, does your API Key have the Feed API right enabled or if you are impersonating a user, does that user have the ability to publish packages?
Also, when you set your NPM auth using:
[~]$ npm config set always-auth=true
[~]$ npm config set _auth={ENCODEDAPIKEY}
Are you base64 encoding your API Key using the format api:{APIKEY}
. For example:
If my API key is FakeApiKey
, I would want to base 64 encode api:FakeApiKey
would be YXBpOkZha2VBcGlLZXk=
. So the commands to run would be:
[~]$ npm config set always-auth=true
[~]$ npm config set _auth=YXBpOkZha2VBcGlLZXk=
Alternatively, you could use npm adduser
to login. Here are some examples:
If you ran the command to make ProGet your default repo: npm adduser --always-auth
If you are using multiple repos: npm adduser --registry=http://progetrepo/feedname --always-auth
If you are using scoped repos: npm adduser --registry=http://progetrepo/feedname --scope=@inedo --always-auth
This way uses a username and password. If you want to use an API key, use API as the username as the API Key as the password.
Hope this helps!
Thanks,
Rich
Are the server BuildMaster is running on and the FTP server using a different culture? For example, is Buildmaster en-EU
and the FTP server en-US
? It looks like the FTP server is sending the date as M-d-yy
, but BuildMaster is expecting d-M-yy
.
Thanks,
Rich
Hi @msimkin_1572,
It looks like your application pool user does not have read/write access to C:\ProgramData\ProGet
. Could you please verify access to that folder and its child folders?
Thanks,
Rich
Hi @msimkin_1572,
Looking at the Azure DevOps documentation here, you should be able to generate a personal access token (PAT) and connect to it using a username as anything and a password as the PAT. In ProGet 5.2, only NuGet v2 API's are supported, so make sure to follow the instructions for connecting it to a NuGet v2 client. In ProGet 5.3 and later, we have added NuGet v3 support.
Could you give that a try?
Thanks,
Rich
Did you download the extension and copy it to the Extensions.ExtensionsPath
folder manually or did you update Extensions.UpdateFeedUrl
to point to the PreRelease Extensions URL? In either case, try restarting BuildMasters site and service. If you did the manual copy way, then upon restart, you should see the version change. If you updated the feed URL, then you should see an update available for your Ftp extension.
Thanks,
Rich
I'm not seeing anything that would cause this. I created a CI version of the FTP extension that includes more logging around the Date parsing. Would you be able to install version 1.0.1-CI.2? You can follow our documentation for installing extensions manually to install this.
Once you have this installed. Could you please repost the error output?
Thanks,
Rich
Hi @dilshaat_6115,
Glad you got it working! Just some extra information for you. The component name is dependent on the component name of the package you updated. In my case, I uploaded a package to ProGet using the main
component. So I had to use deb http://192.168.55.103:8624/ hms-ubuntu main
. Here is an example of how my package looked in ProGet.
Thanks,
Rich
Let me dig into this a bit and see if I can see anything that could be going on.
Thanks,
Rich
Hi @marcin-kawalerowicz_5163 ,
Do you have a proxy set up in front of ProGet? If so, please check the request lengths in your proxy.
Also, what version of ProGet and what version of Docker are you using?
Thanks,
Rich
Hi @bvandehey_9055,
The URL you are using looks correct. IF you click on the Download button and the package actually downloads, then that verifies that it successfully connected. If it was failing to connect to WhiteSource, you would see a page that looks like this:
If you want to verify that ProGet is communicating with WhiteSource, I would just put in a bad value for WhiteSource and attempt to download the package from the ProGet UI. If you get a similar error to above, that verifies the communication to WhiteSource.
Are you using the Product Name or the Product Token in the Product field in the configuration? I would try to use the product token first.
If all of that is setup, then it is most likely an issue with the rules set up within WhiteSource.
Thanks,
Rich
What version of BuildMaster are you running? Also, what version of the FTP extension do you have installed?
Thanks,
Rich
Hi @jyip_5228,
Are you still running the default max connections property? Or have you increased it? Also, how many concurrent builds are you running at a time?
Please send us an update on how the .Net Core version is working out for you.
Thanks,
Rich
Hi @jyip_5228,
I just verified and the fix is still in place. We have seen connection issues in the past with the Mono framework due to how connection sharing is implemented in the mono framework. How often does this issue happen? If you restart the ProGet image, how long before you see the connection pool error?
Just to let you know, as part of ProGet 5.3.10 release, we shipped the ProGetCore
container image as well.
You can follow the normal steps in the Linux and Docker Installation Guide to install/upgrade, but just use progetcore
for the container instead of proget
.
Aside from support for the Lucene-based Maven feed indexing (in progress), it seems to be feature complete. And of course, if there are problems, you can switch back to proget:5.3.10
or downgrade as needed (no database schema changes).
For example, docker pull proget.inedo.com/productimages/inedo/progetcore:5.3.10
Thanks,
Rich
I just wanted to let you know that this was released in 5.3.10. Please let us know if there are still any issues with this.
Thanks,
Rich
For an Ensure-PSModule
command, here is what I'm thinking.
Ensure-PSModule {
ModuleName: ...
Version: ...
MinVersion:...
MaxVersion:...
Force: false
AllowClobber: false
Repository: ...
Credential: ...(I expect this to be a ResourceCredential)
Scope:...
Properties: ... (any other additional properties to pass to Install-Module)
}
Where it just ensures that version (or within the min/max) is installed.
Am I understanding your request correctly?
Thanks,
Rich
Hi @viceice,
Thanks for the clarification on your environment! I see what is going on now. I have created a ticket, PG-1809, to track the fix for this. We expect this to be released in ProGet 5.3.11 which we are expecting to be released in September 11, 2020. Basically in that instance, we are not respecting the values within the X-Forwarded-* headers. I'll let you know if anything changes on the timeline.
Thanks,
Rich
Hi @viceice,
Can you please confirm your connector URL contains the https? How is ProGet setup? Is it installed on windows? Are you using IIS? It might be easier to add an SSL binding in IIS for this as well.
Thanks,
Rich
Hi @viceice,
Is your proxy passing X-Forwarded-Proto
also? That should be passing https
. You could try hard coding that in the proxy.
Thanks,
Rich
Hi @scroak_6473,
I just wanted to send over a few screenshots so you can see what is releasing tomorrow:
When you click on the layer digest on the Vulnerabilities, Repository Vulnerabilities, and Image Vulnerabilities pages, it now will show this modal dialog:
The List Repositories page now looks like this:
The All Tags for a Repository now looks like this:
The All Images for a Repository looks like this:
Thanks,
Rich
I wanted to let you know that this feature has been fixed and will be released in BuildMaster 6.2.17 which is due out tomorrow! I'll reply back if there are any changes to this schedule!
Thanks,
Rich
Hi @ludovic_2596,
Can you please give me your entire ProGet version? Also, what feed type are you having trouble deleteing packages from?
Thanks,
Rich
Hi @viceice,
You should be able to use http://localhost or http://<PROGET_IP_ADDRESS> in your connector without issue. Please give that a try and let me know if you run into any issues.
Thanks,
Rich
Hi @viceice,
ProGet free edition only supports self-connectors when they connect directly to ProGet. If you bypass the proxy, that should resolve the license violations for you.
Thanks,
Rich
Hi @jyip_5228,
That may be your issue. NuGet is currently on version 5.7. Could you please try upgrading your NuGet.exe and see if that fixes the issue?
Thanks,
Rich
We have finally been able to recreate this issue in our sandbox. We are currently looking into a fix, but we expect to have one in the next version of ProGet, 5.3.10. This looks to be an issue with the mono framework. We use mono runtime in our Docker images for ProGet. We are also going to be releasing a .Net Core based technical preview of ProGet Docker in version 5.3.10. This will be in addition to our standard mono based version. Our internal testing is going very well and it looks to have removed a lot of the gotchas that mono has.
Thanks,
Rich
Hi @jyip_5228,
For the v2/v3 thing. If the connector is using v3, there is potential to fall back to v2 if you have issues connecting over teh v3 API. That may be why we are seeing the v2 error.
To follow up on Alana's comment. You may need to use a tool like Wireshark, Fiddler, or Burp to catch the request and response traffic between nuget.exe and ProGet. That would be the only way to see the full response from ProGet and determine if it does attempt v3 before the v2 request.
One last question, what version of the nuget.exe are you using? Is it the latest version?
Thanks,
Rich
This is the first time we have heard any issues with this. We also have not been able to recreate this issue internally. Is there anything unique in your ProGet setup?
Thanks,
Rich
Hi @jyip_5228,
Looking at your last connector error stack trace, it looks like your connector is using the NuGet v2 URL. Would you be able to send a screenshot of your NuGet connector configuration? NuGet has added limiting to their V2 API and I'm wondering if that is causing your issue.
Thanks,
Rich
Hi @gravufo,
After you enabled the Close Database Connections Early
have you tried restarting your web server? You shouldn't have to restart it, but I have seen some issues when there were too many connections open prior to enabling the setting. Coudl you run the following SQL next time you have the issue?
SELECT DB_NAME(dbid) as DBName, COUNT(dbid) as NumberOfConnections, loginame as LoginName
FROM sys.sysprocesses
WHERE dbid > 0 AND DB_NAME(dbid) = 'ProGet'
GROUP BY dbid, loginame
Thanks,
Rich
Hi @john-b_3261 ,
Can you please verify that your ProGet windows service is running and that the account the service is running under has access to those folders? Our nightly cleanup scheduled jobs typically clean up these folders./
Thanks,
Rich
Hi @jyip_5228,
Does this only happen with remote packages? Or do you see this with packages in ProGet as well? When this happens, if you run nuget locals all -clear
on the same account that your build agent is running under, will it work then? I have seen some similar issues like this in the past, but typically they are caused by an issue with local caching in NuGet.
Thanks,
Rich
What version of BuildMaster are you currently running? In BuildMaster 6.2 there is a history on pipeline changes. You would view it by clicking on Deploy -> Deployment Pipelines and then clicking on the last modified date for the pipeline you would like to see history for. Here is a screenshot of the UI:
Hope this helps!
Thanks,
Rich
Hi @dusbn
For the drop path to work. The packages do need to be at the root of the drop path directory. Do you have the packages within subfolders?
Thanks,
Rich
Hi @dusbn,
I think you are looking to use the Drop Path. This would allow you have ProGet monitor a folder and automatically upload a package when it exists in that folder.
Alternatively you could use a PowerShell script to iterate through each nupkg and use nuget push
to push each package.
Thanks,
Rich
Hi @scroak_6473,
You most likely have to setup a Resource Credential. On the Manage User Directories page, you should see a button for AD Credentials
. Create a credential that has domain access. From there, in your domains to search, enter a value of {domain},{Secure Resource Name}
ex: exampldomain.com,DomainAdmin
. Can you give that a try and see if it connects?
Thanks,
Rich
Hi @mcascone ,
We have fixed the issue and the published date will now update when the package is overwritten. This will be released in ProGet 5.3.9 which is due out this Friday Augst 14, 2020.
Thanks,
Rich
Hi @markus4830,
I'm definitely sorry about this. The change was made to help to aide in improvements to other areas of the system related to NuGet. Unfortunately, it looks like it affected the NuGet API. Expect a more permanent solution in the near future.
Thanks,
Rich
I am not aware of any other changes that would have affected that specifically. There were a couple more changes to other areas of the system. It is always possible that there was an update to a Debian package that mono depends on that helped to improve connection handling in Docker. But I cannot confirm that was the case. The only thing I can confirm is that the top two layers in the image have a slight difference to them when comparing 5.3.8 and 5.3.8-ci.20 .
Thanks,
Rich
Hi @Jonathan-Engstrom ,
When you click your name in the upper right corner, go to Edit Profile. On the left you should see a button that says Change Email. Do you see a button there?
Thanks,
Rich
Hi @scroak_6473,
I created a branch and a blank page on GitHub for Docker Swarm. You should be able to add your notes and examples there. Please let me know if you have any issues!
Thanks,
Rich
Glad to hear it! Please let me know if this continues or if you start having issues again.
Thanks,
Rich
Hi All,
We have just released ProGet 5.3.8. Would you please upgrade and test with the Close Database Connections Early
setting enabled?
Thanks,
Rich
Hi @jyip_5228 ,
We just released ProGet 5.3.8, which includes the Close Database Connections Early
option in the advanced settings. Could you please upgrade and give this a try?
Thanks,
Rich