We've published a package with two artifacts in it (android and os) to Bintray: https://dl.bintray.com/gojuno/maven/com/gojuno/commander/
Then we've enabled sync with jcenter for this package, but only one of the artifacts is in sync (android is synched while os is not):
https://jcenter.bintray.com/com/gojuno/commander/
I contacted Bintray through Inbox on bintray.com, Contact Us on bintray.com, Email and Twitter and haven't received reply anywhere, this issue is blocking for the project.
I saw similar issue was resolved through StackOverflow Bintray and JCenter not in Sync, so this is my hope.
An inclusion to JCenter always uses an allocated path prefix to avoid accidental file overwrites by other users. However, the 'commander' package contains files with no common base path:
'/com/gojuno/commander/os' AND '/com/gojuno/commander/android'
The best practice we recommend is creating a new package and not creating more than one path prefix for a package. If you wish keep working like this, please note that you will have to submit an inclusion request for each path prefix.
As for now you may proceed working on the same groupID path prefix with your different sub-modules.
We hope this clarifies.
usually when changing the artifact path you won't be able to resolve your content through JCenter although it was previously included.
The reason for this is that the inclusion of your 'commander' package in JCenter is for the files’ path.
Therefore, it was originally included under the path prefix 'com/gojuno/commander/android/'.
However, we have re-linked your package on the GroupId level (com/gojuno/commander) so every sub-module of your 'commander' package, will be added automatically and be synced with JCenter.
Related
For two Bintray packages, we're publishing multiple artifacts in:
com.criteo.mediation.mopub:criteo-adapter and com.criteo.mediation.mopub:criteo-adapter-development for https://dl.bintray.com/criteo/mobile/com/criteo/mediation/mopub/
com.criteo.mediation.google:criteo-adapter and com.criteo.mediation.google:criteo-adapter-development for https://dl.bintray.com/criteo/mobile/com/criteo/mediation/google/
But only the two criteo-adapter-developmentartifacts are synchronized on JCenter:
https://jcenter.bintray.com/com/criteo/mediation/mopub/
https://jcenter.bintray.com/com/criteo/mediation/google/
The expectation is to get all artifacts to be synchronized.
We have another package with a similar setup that is working well currently: https://jcenter.bintray.com/com/criteo/publisher/
I saw other similar issues on SO such as Bintray does not sync one of the artifacts of the package to the jcenter, but unfortunately, there seems that we cannot take any action except posting a new SO question.
Please note that when you submit a JCenter inclusion request for a particular package, all the artifactIDs present under the groupID will be included in the JCenter. If you add additional artifactIDs under the groupID , which is already linked to JCenter , those artifactIDs will not be mirrored in JCenter because JCenter hosts Single path for a single package.
In your case for the package "publisher-sdk-mopub-adapters", there are two artifactIDs under the groupID com/criteo/mediation/mopub
criteo-adapter
criteo-adapter-development
Only the first artifactID criteo-adapter-development is included in JCenter, In order to add the other artifactID, create a new Bintray package and include all the files under the path GroupID+ artifactID i.e com/criteo/mediation/mopub/criteo-adapter-development so that the package will be hosted in JCenter under the path https://jcenter.bintray.com/com/criteo/mediation/mopub/
I am trying to add a universal package feed as upstream source for another universal package feed in a different ADO project (but same org) but I do not find in the UI the right buttons.
According to this documentation it should be possible to upstream in the same org: https://learn.microsoft.com/en-us/azure/devops/artifacts/how-to/set-up-upstream-sources?view=azure-devops
Am I missing something here?
Universal Packages does not yet support upstream sources, but will very soon (no dates to share, sorry). If the docs suggest otherwise, they may have gotten out ahead of us.
"(new_)git_repository" and "(new_)http_archive" workspace rules deal with external projects in such way that any external dependency is copied to temporary directory linked to workspace as ${WORKSPACE}/bazel-workspace/external/${EXTERNAL_DEP_NAME} on build or prefetch.
I'd like to save external dependencies locally in my repo, so if remote repository vanishes i'd have copy of dependency even on a new machine, where it wasn't cached.
Can I somehow change default behaviour without writing custom workspace rule?
Bazel does have a flag you could use for this: --experimental_repository_cache. It is designed to be a system-wide cache so that multiple projects on one machine don't have to re-download dependencies, but you could use it per-repository. Basically you'd say:
bazel build --experimental_repository_cache=$PWD/my_cache //foo
Then all external repositories would be downloaded to the my_cache directory in your project.
This is a cache keyed by the hash of your external dependencies' content, so it's not going to be very human-readable, but it would let you keep your external dependencies in your VCS fairly easily.
(Theoretically you could even check in a .bazelrc file to specify this option by default, but --experimental_repository_cache only takes an absolute path right now, so it's a bit impractical. I filed a bug to handle the relative path use case.)
I might be wrong but it sounds like you want to just check it in the VCS. If we're talking about an http archive then download it manually, stick it under the relevant "third_party" sub folder with the BUILD file you craft for it and you're done.
If you want to use Bazel mechanisms to download and check-in the external dependencies then this isn't currently supported.
Maybe you should open an issue
The MSDN documentation lists four options, with limited explanation:
Overwrite "Overwrite existing writable files if they conflict with the downloaded files." Does this apply to all files, or just ones we've told TFS we've edited?
GetAll "Gets all files." What files does TFS not normally get?
Preview "Executes a get without modifying the disk." This one seems pretty clear.
Remap "Remaps existing items on the disk to the server items where the content and disk location are not changing." I have no idea what this means.
Overwrite: will blindly overwrite writable files that you have not pended for edit. If you have marked a file as 'writable' then you have violated the contract with TFS and it assumes that you have done this for a good reason (eg, modifying the file without taking a checkout, because you were working offline). This will generally produce a writable conflict on the file, but if you specify this flag, then the writable file will be overwritten.
This only applies to server workspaces (local workspaces are always writable). This has no effect on files that you have pended for edit. Get will always produce conflicts for files that are edited locally and updated on the server; if you want to update files that are checked out, you must undo the checkout (or resolve the conflict with TakeTheirs).
Get All: will download every file and update it, even if TFS believes that the local version is the same as the remote version and that downloading a new version would be a noop. TFS tracks every version that you have locally, as well as remotely, so this is only useful if you edit files locally without checking them out.
If you have kept them writable, then then - as mentioned above - this will be a writable conflict. If you have then marked them read-only then TFS assumes that you have not made any changes and will not bother updating them when you do a get (because it knows the file contents haven't changed). If you have manually changed the file contents, then marking this will update those files to the server version.
Preview: will just fire events and provide results that indicate what would be downloaded with the given parameters.
Remap: is a clever option that allows you to perform an in-place branch switching (which is very common with some version control systems that branch at the repository level - like Git - but somewhat complicated in TFVC.)
Consider that you have mapped $/Foo/main to C:\Foo, and done a get latest. If you update your working folder mappings so that $/Foo/branches/feature now points to C:\Foo, then issue a get with Remap, then the server will download only the changed files between main and branches/feature, so it's an inexpensive way to update your local workspace to a feature branch.
(If you're looking for an example, this functionality exists in the command-line interface and in Team Explorer Everywhere but not in Visual Studio.)
I've added an svn:externals to my project, and it works great locally via TortoiseSVN. When I use Jenkins to pull from the same repository, it's not showing anything about the externals in the console output.
I read some other questions on here and I made sure my SVN version number in Jenkins was set to (1.6 externals to file) and restarted Jenkins. The problem is still occurring. Any ideas of something else I could set, or something I could use for troubleshooting? Thanks.
Oh, and the external directory is in the same repository, so I don't think it's an authentication issue as it builds fine without a reference to the external files.
I fixed this issue by selecting higher SVN Version Number on Jenkins 2.222.1.
Here is the procedure:
Manage Jenkins -> Configure System -> Subversion Workspace Version
Select at least v1.6. (The default one was 1.4 for me)
I may have had a very uncommon structure, but here's what worked for me...
First of all, here's the directory structure:
--Parent
----folder1
------subfolder1
------svnexternalfolder
----svnexternalfolder
As you can see, I had my svn external folder in two different levels of the project structure, but the Jenkins project was pointing directly at "folder1".
When first configured, it would never pull the files for my svn external folder (whether it was a full checkout, or svn update). This was configured with the svnexternals at the parent level.
My next try was to remove the svn externals at the parent, then specify just the higher location on the parent, then the lower location on folder1. This gave an error since the child svn directory had the same name as the other one.
So I flip-flopped the order of creating the svn external locations and did the child first (on "folder1"), then did the higher one on parent. Once I did that, everything started working.
Hope this helps someone else.
If you're curious about why I configured the directory structure this way, this was a PhoneGap project. apparently cordova/phonegap projects create their directory structures like this, the common folder beneath the parent is the "www" which houses all html, javascript, etc files, then those are also used under the platforms/ios, or platforms/android folders (in my example, I just called it folder1).